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ABSTRACT 



This thesis was undertaken to examine the post-development 
process of verifying the correctness of software programs, 
specifically to evaluate the effectiveness and practicality of 
several proposed methods of verification. Of interest were the 
degree to which utilization of a given method can be said to 
demonstrate correctness and the feasibility for general use of 
that method. The method of research was to study current 
literature concerning software testing and formal proofs of 
correctness, select a well-documented program of intermediate 
size for experimentation, apply selected verification methods 
to that program, and finally to compare the results of the 
several experimental demonstrations of correctness. The 
experiments conducted included a proof of correctness and 
dynamic testing with test data cases selected by a condition 
table method, by path analysis, and by structural decomposition 
of the program. 
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I. INTRODUCTION 



This first chapter reviews the environment in which software 
verification methods are employed and presents generally accepted 
definitions and descriptions of software testing. 

A. THE SOFTWARE PREDICAMENT 

1 . Scope of Software Development 

Ware Myers has characterized the current state of expanding 
programming applications as a serious software predicament (28) . 
The cost of computer hardware has declined significantly over 
the last decade, making more and more applications feasible for 
automation. In 1973 it was estimated that between $15 and $25 
billion were being spent annually on software development and 
maintenance (3). The Department of Defense spent about $5 billion 
in 1976 on computer software (34), and has been doubling the 
number of functions performed by software every few years, 
primarily in converting weapons systems components from analog 
to digital. 

2 . Problems in Software Development 

Unfortunately for the growing user communities, and 

despite the expectations raised with the advent of modern pro- 
gramming practices (MPP) , all is not well with software 
development . 

a. Our ability to estimate time and resources required 
for the design and development of software has not appreciably 
increased. 

b. Most major software projects have required that 
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special support tools be developed, that new automated testing 
aids be generated, or that a new language capability be acquired; 
in short, there is inadequate transfer of technology between 
projects within single organizations, and even less among organi- 
zations . 

c. An unreasonable share of software effort has been 
expended on maintenance of existing programs. Estimates of 75% 

or more of a company's programming effort being devoted to mainte- 
nance have not been uncommon. 

d. The rate of increase in programmer productivity has 
not kept pace with the introduction of improved management and 
programming methodologies, let alone with the rapidly increasing 
hardware capabilities; in fact, we are still struggling to learn 
to measure this productivity. 

e. The quality of software has been less than desired. 

While there is no agreement on how to quantify the quality of 
software, many shortcomings are apparent (4): software is still 

difficult to read, understand and modify; programs are frequently 
hard to use .properly and easy to misuse; they are often lacking 
in sufficient generality to be used in several applications or 
transported to different machines; and program reliability has 
been disappointing. 

The applications planned for automation require bigger and 
more complex systems than ever before. Dijkstra pointed out 
that complex systems which are perhaps one thousand times larger 
than existing system cannot be constructed with the same 
techniques used to compose the smaller systems; order-of -magnitude 
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leaps in scale cannot be treated as gradual increases that can 
be handled by simple induction (10) . A systematic and scientific 
method to accomplish functions of such magnitude is required. 

Improvements in the reliability of software (the extent 
to which programs can be expected to satisfactorily perform 
their intended functions) are desired without incurring the 
staggering costs of totally exhaustive testing. That reliability 
needs improvement seems obvious. The relative level of program- 
ming effort devoted to maintenance of existing programs bears 
testament to the existence of errors in programs presumably 
tested and certified correct prior to their release for use. 

Even diligent application of the modern programming practices 
by talented programmers has not necessarily produced reliable 
software. Gerhart and Yelowitz (15) identified errors in pro- 
grams that were published to demonstrate these MPP , errors in 
specifications, in construction, and in programs formally 
"proven" correct! 

B. SOFTWARE ENGINEERING 

1 . Current Trends 

A discipline has arisen, referred to as software engi- 
neering, which draws from established principles of science 
and engineering in attempting to formally define a systematic 
approach to software development. While the goals of this 
discipline are broad in scope, the application of software 
engineering toward attainment of correct software is of 
particular interest. 
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Recent trends in software engineering have emphasized the 
role of design and implementation in preventing errors over 
the role of testing to detect errors for correction. These 
techniques include : 

a. More thorough analysis and definition of requirements: 
The lack of adequate system specifications has been a major 
cause of software shortcomings (12). 

b. Modular design of programs. 

c. Top-down design and implementation techniques. 

d. Management practices such as the use of the team 
concept (possibly including the chief programmer team concept), 
project workbooks, formal documentation requirements, formal 
and peer review, and structured walkthrough of code. 

e. Structured programming: This concept is at the core 

of modern programming practices . While many managers complain 
that they encounter resistance in implementing structured pro- 
gramming in their organization (5), there is growing data to 
support the proposition that structured programming techniques 
can produce more reliable and more cost effective software 
systems (28) . 



2 . Need for Post -Development Testing 

The experience of the research reported in later chapters 
of this thesis confirmed the need for greater relative emphasis 
on design and implementation techniques as compared to verifi- 
cation techniques. Much of the process of constructing a formal 
proof of correctness of the sample program selected for experi- 
mentation was clearly a duplication of the design and implementation 
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effort; it was necessary to analyze the completeness and con- 
sistency of the program specifications, verify the particular 
modular design selected, justify the control flow of each pro- 
cedure, and determine the reasoning behind the choice of 
particular stopping criteria for program loops. To a somewhat 
lesser extent the same was true of the most rigorous of the 
dynamic testing strategies employed (Chapter III, Section C) . 
The duplication of effort is simply not cost effective. 

The successful and widespread use of as yet undeveloped 
techniques that will ensure development of correct software 
programs lies many years ahead. For the foreseeable future, 
programs under development will need to be subjected to an 
effective and practical ex post facto verification process. 
Diligent application of existing program testing techniques has 
been shown to enhance the software development process (1,2,6). 
Significant efforts are required in applying the discipline of 
software engineering toward refinement or replacement of the 
verification methods now in use. 

C. DEFINITIONS IN SOFTWARE TESTING 

Methods of testing or proving the correctness of software 
have been developed until quite recently on an ad hoc basis, to 
fill particular needs in the field rather than to build a 
complete scientific model for the verification process . The 
terms used to describe the activities involved in demonstrating 
correctness have likewise evolved sporadically. The following 
definitions are widely but not universally accepted. 
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1 . 



Correctness of Software 



The central issue in software testing, verification, 
validation, or similar terms is a demonstration that the software 
at hand is correct; i.e., that the given software system produces 
the intended results. The assertion that a program is correct 
is in effect a statement that it performs precisely those func- 
tions, and only those functions, called for in its specifications, 
and furthermore that its specifications are an accurate repre- 
sentation of a design suitable to satisfy the intended require- 
ment. The term "correctness" has a connotation inclusive of and 
stronger than the notion of reliability of software, which was 
defined earlier as the extent to which programs can be expected 
to satisfactorily perform their intended functions. A thorough 
demonstration of correctness involves more than showing that a 
program satisfies some written specifications; it involves an 
analysis of the completeness, clarity, and consistency of the 
specifications as well. 

2 . Debugging 

This term has frequently been used synonymously with 
testing, but should be distinguished in the following sense: 
testing is a process to uncover errors, while debugging begins 
when an error has been detected and is the process of isolating 
and correcting these known errors. A succinct statement of this 
distinction is : 

When debugging is completed the program definitely 
solves some problem. Testing seeks to guarantee 
that it is the problem that was intended (18). 
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3 . Testing 

Testing has just been distinguished from debugging. In 
Reference 24 five major activities in testing were defined, using 
the terms most commonly accepted in practice: 

a. Verification is the process of establishing logical 
correctness of a program (i.e., correspondence with formal require- 
ments) in a test environment. Verification is typically accom- 
plished by actual program execution using selected test data. 

This process of dynamic execution is the single activity most 
often intended by use of the general term testing. 

b. Validation is the process of establishing logical 
correctness in some given external environment, although not 
necessarily in the operational environment. 

c. Proving is the mathematical establishing of logical 
correctness without regard to the environment; it does not 
involve program execution. 

d. Certification is an organizational endorsement that 

a program meets certain standards of correctness and effectiveness 
in a useful environment. 

e. Performance testing is the demonstration of non- 
logical properties, usually execution timing and throughput 
capability . 

4 . Verification and Validation 

Verification and validation is a currently popular term 
used to describe the processes involved in testing software 
prior to user acceptance; used as such the term actually encom- 
passes to some degree all five of the above testing activities 
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(with the frequent exception of proving) . 

5 . Scales of Testing 

During the development and operation of a software system, 
differing scales of testing must be performed. Traditional 
scales of testing are unit testing, integration testing, and 
regression testing. 

a. Unit Testing 

Unit testing is the testing of the independent modules 
comprising the functional decomposition of a large system. Testing 
at the unit level involves examination of the internal logic of 
the module to ensure that the module's effects on the larger 
program containing it are consistent with those effects required 
by the specification, and verification of the assumptions made 
within the module about the larger program. Because specifications 
are frequently ambiguous, unit testing often results in reexami- 
nation of the unit specification. 

The two methods employed in unit testing are functional 
(black-box) tests, which are based on no knowledge of the inter- 
nal structure of the program, and logical tests which are based 
on program structure. Selection of test data which are appro- 
priate for an ideal test (as described in Chapter II, Section A) 
is difficult or impossible for black-box testing because it is 
impossible to distinguish data that are treated similarly or 
differently internal to the black-box. Therefore program veri- 
fication tests by the developer are nearly always based on pro- 
gram structure. Acceptance testing by the user is generally 
functional in nature of necessity. 
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b. Integration Testing 

Integration testing is conducted to determine the extent 
to which a system meets its specifications in an environment 
similar to its working environment. The focus of integration 
testing is on module interaction as opposed to internal module 
operations. When unit testing has been conducted thoroughly 
beforehand, integration testing is primarily a verification that 
modules do not modify those relationships in the environment 
that the specification states must be preserved (e.g., that pro- 
tected portions of memory have not been affected and that global 
variables have not been modified in an undesirable or unantici- 
pated manner) , and a thorough test of the consistency of the 
specification itself. Were the techniques of formal definition 
of requirements and automated verification of specifications 
more developed, integration testing would be less than the 
crucial and expensive effort it so often has become. 

The relationship between unit and integration tests is 

formalized by the following theorem which is the basis for 

demonstrating the correctness of software by testing or proving: 

If it can be demonstrated that each module in 
a system meets its specifications assuming only 
that all submodules meet their specifications, 
then the entire system is correct ( 16 ) . 

It should be noted that the demonstration required by the 
above statement is essentially a verification that the inter- 
actions of modules are consistent with the specifications. 

There is controversy over the best strategy for sequencing 
unit and integration tests. The classical strategy of bottom-up 
testing proceeds from unit to integration tests as lower-level 
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modules are completed, and requires test program drivers to run 
lower-level module tests until the calling modules are ready to 
be incorporated. Common criticisms of this strategy are the 
duplication of effort in writing driver programs, the cost in- 
volved since execution of higher-level modules involves reexecu- 
tion of the lower modules, and most severely the fact that inte- 
gration errors if present are discovered at a late stage in 
development, thus inflating the cost of their correction. 

The top-down testing strategy is much heralded as an integral 
part of the top-down design technique, but it is little practiced . 
Its benefits are purported to be the early detection of specifi- 
cation errors relating to interfacing, since the high-level pro- 
gram skeleton is coded and executed first, with simple dummy 
programs required as sub-program stubs. These stubs are to be 
replaced by the actual lower-level modules as they are written, 
thus facilitating the check-out of new modules one at a time 
while continually verifying the correctness of module interfaces. 
In introducing the concept of a built-in package of "test pro- 
cedures" deliverable with a software product, Panzl contends 
that neither of the above goals are well served by the top-down 
strategy (30) . He states that top-down testing discourages 
thorough testing of lower-level modules because they are never 
executed directly; in fact, it is often difficult to find an 
input data combination that will force execution of a desired 
submodule . 

In practice a mix of top-down and bottom-up strategies has 
been used. Unfortunately, a common choice of strategies is to 
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defer all testing until the entire system can be tested. This 
all-at-once strategy is costly in execution time because all 
modules must always be present, and costly in effectiveness be- 
cause the intellectual task of isolating errors is greatly magni- 
fied when a systematic strategy is missing. However, it is the 
most prevalent testing strategy today (30). In fact, the experi- 
ments in testing and proving which are reported in the following 
chapters of this thesis were performed in an all-at-once fashion 
by virtue of the fact that a program which had completed develop- 
ment was the subject of the experiments. Even so, elements of 
bottom-up testing were apparent in several of the strategies used, 
c. Regression Testing 

Regression testing is the reverification and revalidation 
of software after adding new capabilities or after performing 
maintenance to correct errors discovered in operation. Its 
purpose is to verify that the desired modification and none other 
has been made. Regression testing has until recently received 
very little formal attention (12), which is puzzling in light 
of the previously mentioned estimates of the percentage of 
programming effort devoted to maintenance. A simple management 
technique to enhance regression testing is to ensure that the 
test cases produced during development testing are collected 
and documented as a package, and maintained to be reexecuted 
after maintenance. If extensive maintenance is performed, addi- 
tional analysis of the thoroughness of test achieved with the 
saved data should be conducted. While the test procedures 
suggested by Panzl (30) add to the effort of development, their 
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value at regression test time merits careful consideration of 
the idea. 



D. APPROACHES TO DEMONSTRATING CORRECTNESS 

As suggested earlier, testing is a discipline that has been 
learned through application, with little formal basis until 
very recently. The first major collection of testing concepts 
resulted from a 1972 conference at the University of North 
Carolina, the proceedings of which were published in book form 
by W. C. Hetzel (18). The first significant attempt to establish 
a mathematically-based theory of program testing was a paper by 
John B. Goodenough and Susan L. Gerhart (17); this theory is 
discussed in Chapter II. 

In the development of testing methods, two complementary 
approaches arose, static analysis and dynamic testing. Methods 
that have been employed in an. attempt to show correctness have 
ranged from purely static (e.g., formal proof of correctness) 
to purely dynamic (e.g., execution of the programs with randomly 
selected test data) , although usually a combination of the two 
approaches has been used. 

1 . Static Analysis 
a. Capabilities 

Static analysis refers to a wide range of activities 
that can be performed without program execution (although more 
and more such activities involve automated analysis of source 
programs by software tools). Quite often static analysis is 
perfomred prior to live testing to help in test planning and 
test data preparation. The technique can in itself detect errors 
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in logic (such as uninitialized variables) and questionable 
software practices (such as initialized but never referenced 
variables) . It can also be used as a means of enforcing pro- 
gramming standards. 

The most familiar form of static analysis is program checking, 
or desk checking. While automated static analysis techniques 
of significant capability are being developed, thorough desk 
checking is still an efficient method for insuring software 
correctness. When formalized by management in effective peer 
review or structured walkthrough policies, program checking is 
"very effective" in reducing errors (1) . Program checking can 
detect syntax errors, undeclared variables, unreachable program 
segments, etc. 

Directed graphs of program control flow and data flow are 
common tools of static analysis, and are the basis for the path 
analysis techniques of dynamic testing. Graphs of data flow 
lend themselves to detection of errors in initialization and 
referencing of data. Control flow graphs provide visual evidence 
of program adherence to structured programming practices and 
offer several measures of program complexity. Considerable study 
of the relationship between program structure and complexity 
and resultant error characteristics has been conducted at the 
Naval Postgraduate School (most recently reported in Ref. 35). 

A strong relationship has been found to exist between complexity 
and errors, suggesting that complexity measures may be used to 
establish programming standards (note that constructs of 
structured programming have lower complexity measures than 
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non-s tructured constructs) and to indicate how to allocate 
scarce testing resources. 

b. Automated Aids 

Particularly when dynamic testing is to be performed 
with the number of paths tested as a criterion, static analysis 
techniques are used to aid in developing test cases, frequently 
by automation. Fairley (12) suggests that static analysis 
algorithms (including cross-reference tables, numbers of 
occurrence of statement types, number of subprogram calls, graph 
analysis, etc.) can and should be included in compilers. 
Ramamoorthy et al. (32) discuss the techniques and problems 
involved in automated generation of test data inputs selected 
to satisfy varying requirements for coverage of the branches 
of a program graph, and describe a prototype generator included 
in their Fortran Automated Code Evaluation System (FACES) . 

c. Limitations 

Whether test data is generated manually or by auto- 
mated means, there is unfortunately no reliable way of automating 
the computing of the correct output. Needless to say, dynamic 
testing presupposes a known (or at least bounded) output, and 
specifications must be available for each program tested. A 
limitation in the degree of testing which is feasible is fre- 
quently imposed by the difficulty of determining the desired 
output . 

A serious limitation of static analysis, and particularly 
of test case generators, is the decidability problem (12). 
Algorithms may be easily written to identify all syntactic 



23 



paths of control flow in a program, but it is not possible to 
algorithmically determine the semantic paths (those syntactic 
paths which can in fact be executed for some set of input data) . 
Therefore it is not possible for all programs to determine 
whether some statements (including termination statements) can 
be executed for any input data. In these cases dynamic testing 
or the more difficult techniques of symbolic execution or proofs 
of correctness are often used to decide the question. 

2 . Dynamic Testing 

Dynamic testing is the process of actual program execu- 
tion to provide evidence upon which some conclusion may be 
reached as to the correctness of the software. Applications 
of theoretically-based testing methods (as described in Chapter 
II) have not yet countered Dijkstra's pronouncement that "Program 
testing can be used to show the presence of bugs, but never to 
show, their absence!" (10). Nonetheless, dynamic testing has 
been and will remain the most common evidence proffered to show 
program correctness or reliability. 

a. Selecting Test Cases 

The critical activity during dynamic testing is the 
selection of test cases. Intuitively it is desirable to select 
a set of test cases which are representative of the actual input 
domain the program will have to contend with during operation. 

The principle guide in selecting test cases has been to test 
for the likely kinds of errors in the program, particularly in 
the program modules deemed most critical to proper program 
operation. Since it is not possible to anticipate all the 
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possible errors, it is unlikely that this principle alone can 
be relied on to select a suitable set of test data. Selection 
of a data set truly representative of the input domain is parti- 
cularly difficult without knowledge of the internal structure 
of the program (i.e., when doing black-box testing), because it 
is then impossible to distinguish data that are treated similarly 
internally. Knowledge of the program structure can be used to 
identify the complex portions of the program which should be 
subjected to the most thorough testing, and to help identify 
the groups of data that are handled similarly and thus aid in 
selecting those cases representative of certain subsets of the 
input domain. However, use of this knowledge is of limited value 
in that there is no certainty that the program structure is a 
correct representation of the conditions required for correct 
operation of the program ( 16 ). 

b. Thoroughness of Tests 

The thoroughness of test, or degree of test coverage, 
is intended to provide a measure of the reliability of the 
testing process. The more thorough the test, the less probable 
that undetected errors remain. Unfortunately, no perfect quanti- 
tative measure of test thoroughness has been recognized, although 
it is clear that the criteria used to select test cases will 
determine the thoroughness of test. 

Typically, estimates of test thoroughness have been based 
on a count of the source statements executed or the program 
control paths traversed. While a test which causes the execution 
of all program source statements may appear thorough, there are 
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numerous counterexamples which demonstrate the actual lack of 
thoroughness (for example, in Ref. 22). Since there are typically 
an infinite number of possible sequences of statement execution, 
any finite tests which execute each program statement at least 
once cannot be said to have tested all possible sequences, and 
thus may fail to reveal all program errors. The path analysis 
strategy of dynamic testing involves execution of selected con- 
trol flow paths in the program under test. Because the number 
of control flow paths may be very large or infinite (due to the 
presence of loops) , practical path analysis strategies are 
limited to execution of some subset of the total paths. Huang 
'defined a "minimally thorough" test as one which caused at least 
one traversal of every branch or arc in the program's control 
flow graph (flowchart) (22); however, such a test cannot assure 
detection of all errors. In fact there is no agreement as to 
what an adequate measure of thoroughness may be (traverse each 
arc twice, traverse all possible arc pairs, etc.). Nonetheless, 
it has been shown that for many programs (651 of a small survey 
of eleven programs conducted by Howden) , path analysis criteria 
are "almost reliable" (21). Given the alternatives, testing 
based on path analysis is today a sound choice, particularly 
when accompanied by careful program checking and a structured 
walk-through of the design itself. 

The discussion in Chapter II of a theory of testing further 
examines the critical matter of thoroughness of tests, 
c. Automated Aids 

Automated aids to support dynamic testing include 
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the experimental test case generators discussed in the section 
on static analysis, and programs which compute the degree of 
coverage of the program graph according to the given path analysis 
criterion. Pimont and Rault (31) describe an implementation of 
such a technique, with a more ambitious coverage criterion than 
most of the path analysis techniques. 

The insertion of software counters in the target branches, 
a relatively simple form of program instrumentation for testing, 
assists in test data selection by providing feedback as to the 
coverage obtained from each set of input data (22, 23). A common 
form of program instrumentation is the use of assertion statements 
expressing the relationships among data which should hold at 
various nodes in the program. During execution the assertions 
are evaluated to check their validity. Program instrumentation 
can also be used to perform data flow analysis by setting state 
flags as variables are defined, referenced, and undefined, and 
noting any illegal state transitions. Program instrumentation 
requires much of the information normally available in a compiler; 
therefore it is becoming a feature of experimental test facilities 
that program instrumentation be performed as a compiler option. 

More extensive instrumentation of the source program is 
involved in execution analysis or execution histogram systems. 

Such systems have as a goal the creation of a data base of pro- 
gram execution information that can be output in batch fashion 
or remain available for interactive query. These systems facili- 
tate source language debugging, can provide control and data 
flow information, environmental information, assertion checking, 
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tracebacks, etc. The information can aid static analysis and 
dynamic testing (path analysis or other) . There are drawbacks 
to these systems: very high cost, both in development and use, 

lack of generality (machine and language dependent usually), 
and the attendant problems of handling the large data bases that 
can be created. Fairley describes an Interactive Semantic 
Modeling System (ISMS) implemented experimentally for application 
to Algol 60 prgrams (11) . The Naval Sea Systems Command has 
successfully used a software processor AUDIT to aid program 

verification and to monitor adherence to structured programming 

/ 

standards (71) . 

Program instrumentation in most cases involves modification 
of the source code, and generally incurs an unacceptable per- 
formance penalty (as does the evaluation of assertions). There- 
fore it is common to remove such instrumentation from production 
programs, and to repeat dynamic testing with the optimal set of 
test data to ensure that program performance remains correct. 

There are two simpler automated aids to dynamic testing 
that should be mentioned. Generators of random test data are 
not uncommon; although random data do not generally provide a 
thorough test, they are easy to obtain. While automated compu- 
tation of the expected results of tests is not feasible (because 
such computation amounts to automation of the function of the 
program under test and is the object of verification) , automated 
comparison of actual results with the expected results is practical, 
and useful as a labor-saving aid. The expected results are 
typically computed by hand or determined from historical data. 
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or bounds defining reasonable results are established if compu- 
tation is overly difficult, 
d. Limitations 

Limitations to the effectiveness of dynamic testing 
at ensuring the correctness of software were evident in the dis- 
cussion of the difficulty of determining a reliable measure of 
test thoroughness. An additional drawback to any form of dynamic 
testing is the cost both in time and resources. 

Testing or verification techniques include several indepen- 
dent or even contradictory methods , due to the infancy of soft- 
ware engineering and program testing theory. The rationalization 
of this apparent inconsistency lies in the realization that, 
given the present understanding of software, nearly every soft- 
ware development is a unique and individual design. Cerification 
of such programs requires the testing team to be familiar with 
a variety of testing methods and tools, and to judiciously apply 
those which seem best suited to the task at hand. 
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II. NATURE OF THE PROBLEM 



A. A THEORY OF TESTING 

As alluded to in the first chapter, a tentative theoretical 
basis for the testing of software has been formulated by Good- 
enough and Gerhart (17) . That theory is capsulized in this 
section . 

1 . Types of Errors 

Testing is a process of collecting and analyzing evidence 
relating to the presence of errors. To reach a meaningful con- 
clusion as to the presence of errors, the nature of errors must 
be clear. On a logical basis, errors can result from failure 
in implementing the specification (construction errors) , failure 
of the specification to accurately reflect the design, failure 
of the design to adequately solve the requirements that are under- 
stood, or failure to identify the real requirements. Each of 
these logic errors will ultimately appear as an inappropriate 
effect produced by the implementation, namely as: 

a. missing control flow paths, 

b. inappropriate path selection, or 

c. inappropriate or missing action on a path. 

Recognizing the types of inappropriate effects that may be 

caused by errors, the problem in testing is to select test cases 
that can show that these errors do not arise. As mentioned ear- 
lier, a common criterion for selecting test data is to choose 
data which will exercise each arc or branch in the directed graph 
representing the program at least once. Because logic errors, 
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particularly specification, design, and requirements errors, may 
be manifested by missing paths, it should be obvious that this 
criterion alone cannot select test data that will thoroughly 
test a program. 

2 . Criteria for Test Case Selection 

Goodenough and Gerhart defined an ideal test as one which 
succeeds only when a program contains no errors. They defined 
two predicates about a criterion C for selecting test cases that 
if satisfied are sufficient to establish that any complete test 
is an ideal test (a complete test is one using the criterion C 
to select a set of test data T which are subsequently used to 
dynamically test the program). These predicates, RELIABLE (C) 
and VALID(C) , are defined as follows. A criterion is reliable 
only if all complete tests yield the same (not necessarily 
accurate) result; that is, if one complete test is successful 
(no program errors are revealed) , then all complete tests must 
be successful, and if one complete test reveals an error, all 
must reveal that error. Reliability of criteria refers to con- 
sistency; using a reliable criterion, a second complete test is 
redundant as it can provide no new information. A criterion is 
valid only if for every error that can exist in a program there 
is (at least) one complete test that can show the presence of 
the error. 

The concept of reliability of a criterion for selecting test 
cases is not to be confused with the earlier definition of soft- 
ware reliability as a measure of the extent to which programs 
satisfactorily perform their intended functions. 
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The fundamental theorem of testing that Goodenough and Gerhart 
have suggested is simply that there exist some criterion C for 
selecting test data and some subset T of a program's input domain 
D such that when it is shown that a test using test data T is 
a complete test and that the criterion C is both reliable and 
valid, then success of the test implies that the program is 
correct . 

Stated formally, the theorem is: 

QTsD) (3C) [ (COMPLETE (T,C)aRELIABLE(C) 

aVALID(C) A SUCCESSFUL (T) ) ^ (Vd£D)OK(d) ] , 

where COMPLETE (T,C) is a predicate indicating that the test T 
is complete according to the criterion C, and OK(d) is a pre- 
dicate indicating that program execution with the element d 
from the input domain D produces the results required by the 
program specification. 

The theorem is not profound; its proof is simple and is 
assured by the convenient definitions of reliable and valid 
criteria. If there is some complete test capable of revealing 
any error (valid criterion) and if all complete tests yield the 
same result (reliable criterion) , then clearly any complete 
test based on a valid and reliable criterion must correctly 
demonstrate the presence or absence of errors. 

For the skeptic, a proof of the theorem may be written as 
follows : 

- As to the existence of such a T£D and criterion C, either 
the program is correct or it is not. If it is correct, then a 
criterion C such that a complete test T is (d) , where d is any 
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element of D, will satisfy the theorem. If the program is not 
correct, there is some element d€.D such that — jOK(d) . Then a 
criterion C such that T={d} is a complete test. In either case, 
the required conditions are satisfied, and the criterion and 
test set exist (the challenge for the program tester is to dis- 
cover them) . 

- As to the theorem's implication, assume the truth of the 
hypotheses and assume (fidtD) — jOK(d); i.e., assume the theorem 
is false. 

- Then VALID (C) (3-Ts.D) [COMPLETE (T ,C) a. SUCCESSFUL (T) ] . 

- Then RELIABLE (C)=§>"all complete tests fail." 

- But this contradicts an hypothesis of the theorem, namely 
(3T9D)SUCCESSFUL(T) . 

- End of proof. 

Use of the theorem is not an easy matter. A criterion for 
selecting test data must be chosen and that criterion must be 
proven reliable and valid. Techniques using dynamic testing to 
"prove" software correctness will be practical only if the proofs 
of criterion reliability and validity are simpler to construct 
and at least as convincing as proofs of program correctness. 

The experiments reported in this thesis examined some aspects 
of applying the above theorem. 

B. SATISFYING THE PREMISES OF THE THEORY 

1 . Formal Proofs of Correctness 

A degenerate application of the above fundamental 
theorem of testing is selection of a criterion C such that a 
complete test is complete only if T is the null set; in this 
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case, no testing is done. The criterion C is clearly reliable 
since there can be no tests. To show that C is valid (any 
possible program error will be revealed by at least one convnlete 
test"), it must be shown that the program has no errors at all. 
Application o^ the theorem with such a criterion is therefore 
equivalent to a proof of program correctness. Such a proof 
was constructed for the sample program of this thesis (Chapter 
IV, Section B) . 

2 . Symbolic Execution 

Symbolic execution is a technique whereby symbols are 
used as input values rather than real data elements and the 
program is symbolically executed by replacing all data operations 
with symbolic operations. Intermediate results then are compu- 
tational expressions of the input symbols rather than data 
objects. In the case of conditional branching in the program, 
logical statements on the input symbols, called path conditions, 
describe the conditions under which a given control path may be 
traversed. Program correctness is shown by proving that at 
termination the constraints of path conditions imply that the 
computational expressions of input symbols are equivalent to 
those required by the program output specification. That proof 
and the required proof of similar intermediate theorems con- 
stitute a general theorem-proving problem; automated theorem- 
proving capabilities are currently quite limited, and proving 
the theorems by hand is quite tedious. This drawback restricts 
the practical use of formal proofs of correctness as well. A 
system for symbolic program execution is described in Ref. 8. 
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Symbolic execution is related to the theorem of testing in 
that the criterion C is to choose input symbols satisfying the 
program's input specification; to show the reliability and 
validity of C, it must be shown that the output specification 
of the program can be expressed as a computational expression of 
input symbols and that the intermediate expressions are valid 
over the entire domain of values for input symbols. 

The technique of sumbolic execution was not directly applied 
in these experiments; however, the experiment using test data 
execution and the principle of distributed correctness (Chapter 
IV, Section C) relied on some of the ideas of symbolic execution. 

3 . Test Data Execution 

Clearly one ideal test is execution of the program for 
every member of the program's input domain. Since most input 
domains are infinite, this test is usually impossible and nearly 
always prohibitively costly, and can therefore hardly be called 
ideal in any practical sense. Goodenough and Gerhart used in 
Reference 17 a "condition table method" to select test data for 
program execution. While they were not able to conclusively 
prove the reliability or validity of this method as a selection 
criterion, they attempted to show that they did identify equiva- 
lence classes covering the input domain of an example program 
and choose a representative of each class which by induction 
tested each member of that equivalence class. The condition 
table method was incorporated in an experiment of this thesis 
in conjunction with the distributed correctness principle. 
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Test data selection techniques such as path analysis and 
independent sub-structure analysis are also attempts to identify 
equivalence classes in the input domain, while again only in- 
formally trying to establish criterion reliability and validity. 
These techniques were used in the experiment reported in Chapter 
IV, Sections D and E; in each case, however, it was not possible 
to determine whether the equivalence classes identified actually 
covered the input domain until comparison with the results of 
other experiments . 
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III. EXPERIMENTAL PROCEDURES 



An example program was selected for experimentation, and 
several verification methods were applied to demonstrate the 
correctness of the example program. The hours of effort required 
for each method were recorded and qualitative assessments were 
made about the degree of difficulty of using each method. The 
example program and the methods employed are described in this 
chapter; the actual results and a comparison of the methods is 
presented in the next chapter. 

A. THE PROGRAM AND INTUITIVE TEST DATA 

1 . Origin and Description 

Reference 20 is a report of an experiment in software 
error occurrence and detection conducted at the Naval Post- 
graduate School. Four programming projects were undertaken and 
data were recorded on the man-hours expended in each development 
phase, time of detection and occurrence of errors, and man-hours 
expended correcting errors. Errors were classified according 
to the development phase in which they occurred and by descriptive 
types, and were analyzed with respect to development phase, 
correction time, and program complexity. 

Project number one of Reference 20 was chosen as a program 
for experimental verification. The subject program reads and 
processes a variable length string of text characters, recording 
all occurrences of palindromes (sub-strings which read the same 
forward or backward) , including overlapping palindromes and 
omitting palindromes entirely included with another. The program 
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was written in Algol -W to run under OS/MVT. It contains 141 
source statements and consists of the main program and ten 
procedures, five of which are significant to the palindrome- 
finding algorithm; the remaining five are called to print the 
results. The original program development required 5.0 man- 
hours in the design phase, 7.0 in the coding phase, 4.0 in 
debugging, and 5.8 hours in the original testing phase. 

2 . Program Listing 

Figure 1 is a listing of the palindrome program. 
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begin 

comment This program finds palindromes within a character string 
of maximal length = 256. 

Minimum string length is 2. 

All input cards will be listed. 

The program will produce a list of only those palindromes 
which are not entirely Included in a larger palindrome; 



c o mme nt data declaratio ns ; 

string( 1) array text( 1: :256) ; 

string(80> cardbuffer; 

Integer array beg 1 n_o f-pa 1 indro me , 
Integer cardlimit, length_o f_text , 
pa 1 indrome— counter ; 
integer ix, jx; 



c o mine nt initialization; 

procedure initialize; 

comment initialize all variables, read length— o f— text , write text! 

begin 

text 1 ; 

J x : = i ; 

pa 1 ind rome —count er * = 1 ; 
card i imi t • =80 ; 
intf lelds ize • =5; 
read< lengt h— o f — te xt ) ; 

if (( lengt h—o f— text < 2) or ( leng t h— o f — tex t > 256)) then 
begin 

write( "Ille ga 1 1 npu t : M , 

" length of input string is: ", length— o f— text ) ; 

asser t ( false) ; 

end ; 

cardbuffer : 25 " " ; 

end initial ize ; 



comment utilities; 

procedure b lank— 1 ines( Integer va 
c o mme nt write n blank, lines; 
begin 

integer i; comment 

assert(n>0); comment 

for i:=l step 1 until n do write 
end blank— lines; 

procedure text i ; 
begin 

write("Flnd all palindromes within the following string:"); 
b lank— 1 ines ( 2) ; 

wr i le ( "Card Text " ) ; 

wr i te( ’Number " ) ; 
b lank— i ines ( i ) ; 
end tex t 1 ; 



lue n) ; 



local counter; 
safety check; 

( ■ " ) ; 



comment contains character 
a t r i ng ; 

comment i/o buffer for cards; 
end_o f — pa 1 indro me ( 1 : : 256) ; 
bufferpoaitlon, card-counter, 

c o mme n t i nd ex variables; 
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procedure text2; 
begin 

b lank_ 1 lnes ( 2) ; 

write("The following palindromes have been detected:"); 
b 1 ank-1 1 nes ( 1 ) ; 

wr i te ( "Pa 1 Indrome Begin End"); 

wr i te ( "Number Card Character Card Character"); 

wr i t e ( " Number Position Number Position”); 



wr i t e ( ” — — — — — " ) ; 

wr i teon( " ” ) ; 



end text2; 

procedure text3; 
begin 

write("No palindromes found. End of run."); 
end text3; 

procedure read— and— wr 1 te— input —cards ; 

comment read input cards according to given length— o f— text ; 
begin 

integer number— o f— input— cards ; 

number— o f— input— cards := ( 1 eng t h—o f —text - i) d iv cardllmlt + 1; 

i x : = i ; comment reset text index; 

for card— counter : = 1 step 1 until number— o f —input— cards do 
begin 

wr i te ( card— counter ) ; 
writeon(" "); 
readcard ( c ardbuf f e r ) ; 
wr i teon( cardbuf f er ) ; 

buf ferpoe? i t ion : =0 ; comment reset index; 

while ( ( i x< = 1 engt h_ o f _ text ) and ( buf f erpos i t ion< card 1 imi t ) ) do 
begin 

text ( ix) :=cardbuffer(bufferpositionl 1) ; 
i x : = i x+ 1 ; 

bufferpos i t ion: =buf ferpos i t ion+1 ; 

end; comment done for ail characters on a card; 

end; comment done for ail cards; 

end read— and— wr 1 te— input— cards ; 

procedure wr i te_ a 1 1_ pa 1 indromes ; 

comment list all palindromes being found; 

begin 

integer i,j; comment local counters; 

text2 ; 

for i : = 1 step 1 until jx-1 do 
begin 

If end-o f— pa i indrome ( i ) 0 then 

begin 

wr i te ( pa 1 iudrome-coun ter ) ; 
writeon(” 11 ) ; 

wr i teon( (( begin— o f— pa 1 indrome ( i )- 1 ) dlv cardllmlt) + 1); 

writeon(" " ); 

if ( beg 1 n_o f— pa 1 indrome ( i ) rera cardllmlt = 0) then 
wr itfeon(cardl imi t) 

else 

wri teoa( ( begin— o f_pa 1 indrome( i) rem card limit)); 
wr i teon( " " ) ; 

wr i teon( ( ( end— o f— pa llndrome(l)-l) dlv cardllmlt) + 1); 

wr i t e o n ( " " ) ; 
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) ; 
) ; 



if ( end— o f— pa 1 indrome ( i) rem card 1 iml t =0) then 
writeon(cardl imit) 

e lse 

wr i teon( ( end— of —pa 1 indrome ( i ) rein card i i mi t ) ) ; 
write( " " ) ; 

for J i =begin— of _pa 1 indrome ( i ) step 1 
until end— o f_ pa 1 indrome ( 1 ) do wr i t eon( t ext { j ) ) ; 

wr i te( " 

wr i teon( " 

b lank— 1 lnes ( 1 ) ; 

pa 1 indrome— counter : =pa 1 indrome— count er+ i ; 
end; comment end if; 

end; comment done for all palindromes; 

end wr i te— a 1 1— pa 1 indroraes ; 

comment subroutines; 

procedure pa 1 1 ndrorae— c hec k; 

comment find ail palindromes within given text string; 
begin 

comment scan text from left to right; 
for ix: = 2 step i until 1 eng t h_ o f — te x t do 
begin 

if text( ir- 1) = text(ix) then cont inue_ checking( ( ix- i) , ix) ; 

if ix ~= 2 then 

if text ( ix-2) * text( lx) then cont inue— checkingt ( ix-2) , ix) ; 

end ; 

end pa 1 indrorae— c hec k; 

procedure con t inue— checking (integer value first, last); 
comment Given first and last as pointers to a palindrome 

of size 2 or 3, this procedure checks whether or not this 
palindrome is Included in a larger palindrome; 

begin 

logical palindrome; 
pall ndrome : = true ; 

while ( ( f i rs t > i ) and ( las t< length_o f — text ) and (pal indrome= true) ) do 
begin 

if text(first-i) = text( last+i) then 
beg i n 

comment larger palindrome found; 
f irs t : = f irs t- 1 ; 
las t : - las t + 1 ; 
end 

c lse 

begin 

pa 1 indrome : = f a lse ; comment largest palindrome found; 

end ; 

end ; 

record— pa lindrorae< first, last) ; 
end con t inue— checking; 
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procedure record-palindrome (integer value first, last) ? 
comment Record only max length, palindromes- Flag previously 

recorded palindromes if they are included in the palindrome 
specified by first and last. 

jx was initialized to 1. After completion jx points to the 
next entry In beg in— o f — pa 1 lndrome and e nd—o f— pa 1 indrome ; 

begin 

integer i; comment local counter; 

logical entry; 
entry: = true ; 

for i : = i step 1 until Jx-1 do 
begin 

if ((first> = begi n— o f— pa 1 indrome ( i ) ) 

and ( las t< =end_ o f _ pa 1 indrome ( 1 ) ) ) then 
begin 

comment Palindrome is entirely included in a previons ly 
recorded palindrome. No entry required; 
entry: = f a lse ; 
end 

else 

begin 

if (( beg i n—o f— pa 1 indrome ( 1 ) >= first) 

and ( end— o f— pa 1 i ndro me ( 1) <= last)) then 

begin 

end— o f — pa 1 indrome ( 1 ) : = 0 ; 
comment flag smaller palindrome; 
end ; 

end ; 

end; comment All previously recorded palindromes 

compared with last input; 

if entry = true then 
begin 

comment larger than ail previous or overlapping or disjoint; 
beg in_ o f — pa 1 ind rorae(jx) : = f i rs t ; 
end— o f _ pa i indrome(jx) : - last; 
j x : = j x+ 1 ; 
end ; 

end record— pa 1 i ndrorae ; 



comment main; 
initial ize ; 

read— and— wr i te— input— cards ; 
pa 1 indrome— check; 
if j x= 1 then text3 
else writ e_ a 1 1 _ pa 1 i ndro me s ; 
end . 
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3 . Program Graphs 



Figure 2 presents the control flow directed graph repre- 
sentations of the significant procedures of the example program. 
The graphs, originally presented in Reference 20, are annotated 
with key-words indicating the structured programming constructs 
comprising the decision nodes, lower-case letters which label 
the arcs, upper-case letters representing the counters placed on 
the individual decision-to-decision paths for path analysis, and 
with complexity measures of the procedures. The complexity 
measures shown are defined as follows: 

a. The number of statements is a count of the source 

I . 

code statements m the procedure. 

b. The number of nodes is a count of the nodes in the 
control flow graph. Nodes are points of starting, stopping, 
branching, or merging of control flow; i.e., decision points. 

c. The number of arcs is a count of the arcs in the 
graph. Arcs are concatenations of zero or more program state- 
ments with no decisions except at the nodes. 

d. The cyclomatic number of a strongly connected graph 
is equal to the maximum number of linearly independent circuits 
(27) . A program control flow graph with one entry and one exit 
such that each node can be reached from the entry and such that 
the exit can be reached from every node can be considered as a 
strongly connected graph with an imaginary arc from the exit 
node back to the entry node. For such a control flow graph the 

j || 

cyclomatic number can be variously interpreted as the maximum 
number of independent paths , one more than the number of predicat 



nodes (nodes with more than one path leaving) , the number of 
regions in the graph (plane graph with no arcs crossing) , or 
the number of arcs minus the number of nodes plus two (27) . 

The experimental method described in Section E of this chapter 
makes use of the cyclomatic number. 
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Procedure : 

INITIALIZE 

Number of statements: 14 

Number of nodes: 5 

Number of arcs : 5 

Cyclomatic number: 2 
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Procedure : 

READ_AND_WRITE_ 

I N P UT_C ARD S 

Number of statements: 18 

Number of nodes : 6 

Number of arcs : 7 

Cyclomatic Number : 3 
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Procedure : 

PALINDROME_CHECK 
Number of statements : 7 

Number of nodes: 10 

Number of arcs: 13 

Cyclomatic number: 5 
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Procedure : 

CONTINUE j^CHE CKING 
Number of statements: 15 

Number of nodes : 8 

Number of arcs : 9 

Cyclomatic number: 3 
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Procedure : 

RECORD^PALINDROME 
Number of statements: 21 

Number of nodes: 10 

Number of arcs: 13 

Cyclomatic number: 5 
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Procedure : 

MAIN 

Number of statements : 6 

Number of nodes: 6 

Number of arcs: 6 

Cyclomatic number: 2 
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4. Error Data 



Forty-four errors were detected during original program 
development. Error descriptions by type are recorded in Reference 
20. Table I presents the errors (using Hoffman's original error 
numbering) which could be directly related to a particular pro- 
gram fragment. 

TABLE I 

SELECTED ERRORS 



Error 

Number Procedure Description 



1 read-<-and-«-wr ite. . . 

3 initialize 

4 initialize 

35 palindrome-«-check 

36 • pal indr ome+ check 

37 initialize’ 

42 initialize 



Need for 256-character variable 
"text" in addition to an 80- 
character buffer noted. 

Syntax error. 

Syntax error. 

Error in limits to counter of 
for statement. 

Missing "if ixi=2" resulted in 
indexing error at run. 

"jx" not initialized; resulted 
in indexing error. 

"jx" initialized to 0 vice 1. 



5 . Intuitive Test Cases 

After a first examination of the example program and 
before commencing any of the verification experiments, a set of 
test cases was selected by intuition which appeared to test the 
program's handling of all conditions significant to proper 
program operation. Those test cases are listed in Table II. 

The intuitive test cases were used for conducting additional 
dynamic testing after completion of the experiments using the 
methods described in the remainder of this chapter. 
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TABLE II 



Test 

Number 



1 

2 

3 

4 

5 



6 

7 

8 



String 

Length 



2 

3 

1 

257 

256 



15 

100 

256 



INTUITIVE TEST CASES 

String or 

String Description 

"xx" - length 2 palindrome 
"xyz" - length 3 palindrome 
Invalid string length 
Invalid string length 

A maximum length string containing palin- 
dromes of length 10, 9, 6, and 12, of 
which the first included length 3 palin- 
dromes at both ends, the second and third 
overlapped, and the fourth was written 
across an input card boundary. 

String with no palindromes 
Entire string one palindrome 
One maximum length palindrome 



B. PROOF OF CORRECTNESS 

A method of formal proof of correctness was used to verify 
the logical correctness of the algorithm of the example program. 
The method required the assumption that the environment in which 
the program operates is also logically correct, most particularly 
that the compiler and operating system ensure performance -of the 
expected semantic actions for the program statements. 

References 9,13,19,25 and 26 were consulted to develop the 
methodology for constructing the proof. The work of Floyd (13) 
is considered the basis for mathematical program proofs; the 
paper by Manna and Waldinger (26) was particularly helpful in an 
operational sense, and Hoare's paper (19) was applicable to the 

' 

treatment of procedure calls. 

The first step in constructing the proof was to formalize 

i 

the required result of the program in a logical statement called 
the output assertion, and to describe the restrictions on input 
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data as an input assertion. Translating the rather loosely 
defined purpose of finding palindromes to an output assertion 
required significant analysis of the requirements. 

The proof itself was constructed using the method of in- 
variant assertions to show partial correctness; i.e. , that when the 
input data satisfied the input as sertion , ■ the output assertion 
was satisfied if the program terminated. Termination of the 
program was proven separately by finding for each loop a set 
and an ordering relation on that set such that the set can have 
no infinite decreasing sequences (well-founded ordering), and 
defining a termination expression which is a member of that 
set and which is decreased each time control passes through the 
loop. The proofs of partial correctness and termination together 
establish the "total correctness" (26) of the program. 

The method of invariant assertion involved inserting appro- 
priate intermediate assertions (also called Floyd assertions) at 
selected labels in the program such that they defined a condition 
which would be logically true each time control passed through 
that label (hence the name invariant) . At least one intermediate 
assertion was inserted on every loop. Corresponding to each 
path between assertions a verification condition was written. A 
verification condition is a theorem of the form < assertion 1> 
and < semantic meaning of program statements on path > implies 
< assertion 2 > . Proving all verification conditions completed 
the proof of partial correctness. 

The construction of appropriate verification conditions was 
aided by using the invariant deductive system described in 



53 



Reference 26. The notation (P) F f Q } , where P and Q are logical 
statements (assertions) and F is a program fragment, is used to 
mean that if P holds before executing F and if F terminates, 
then Q holds after executing F. Thus the proof of program correct- 
ness is a proof of the invariant statement: 

{input assertion^ program (output assertion). 

Rules of inference were supplied in Reference 26 to provide sub- 
goals for proving certain invariant statements; in particular 
there is one rule of inference for each statement type in the 
programming language. For instance, the rule for conditional 
statement " if R then F else G" is written as: 

(P and R) F (Q } , (P and -iR} G (Q } 

’(P) if R then F else G (Q) 

The notation signifies that proof of the two invariant statements 
in the nominator of the "fraction" is sufficient to infer the 
invariant statement in the denominator. 

The reference provided rules of inference for assignment 
statements, conditional statements, while statements, and for 
the concatenation of statements. Additional rules were formu- 
lated for iterative for statements and procedure calls. The 
rules are introduced as required in the presentation of the 
proof (Appendix A) . 

C. DISTRIBUTED CORRECTNESS 

Test cases for dynamic testing were selected using a criterion 
based on the condition table method of Goodenough and Gerhart 
(17) and the principle of distributed correctness described by 
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Geller (14). The criterion was not proven reliable and valid, 
but an effort was made to show that the data selected were 
representative of equivalence classes covering the input domain 
of the program such that correct operation for all data in the 
domain could be induced from correct operation for the test data. 

As in the proof of correctness, input and output assertions 
were stated. At selected labels in the program (fewer than in 
the correctness proof) , "synthesized assertions" (14) were in- 
serted, similar to Floyd assertions but more general. The syn- 
thesized assertions expressed invariant conditions of the program. 
A condition table was constructed (if necessary) to analyze all 
conditions affecting program operation from the previous asser- 
tion to the one under consideration. Test data were selected 
for each class identified in the table (similar to the decision 
rules of a limited-entry decision table) , and a "test data 
assertion" was stated, namely that execution of the program 
fragment with the test data would satisfy the synthesized 
assertion. The test data assertion was verified by dynamic 
testing. At the same label, a generalization assertion was made 
attempting to state the conditions for correct operation of the 
program fragment, and where possible the synthesized assertion 
was proven from the test data and generalization assertions. In 
several cases, however, a basis for verifying the generalization 
assertion could not be found and hence the verification method 
could not be claimed to have proved program correctness through 
testing. Certainly, however, an intuitive feeling of "high" 
reliability and validity of the test case selection criterion 
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was established. 



The principle of distributed correctness was called upon to 
infer program correctness from the correct operation of the 
distributed program fragments verified by the synthesized 
assertions . 

D. PATH ANALYSIS 

1 . Basic Technique 

Path analysis techniques are described in References 21, 
22, 23, 31 and 32. For the example program, test data were 
selected to force program traversal of each arc of the program 
control flow graph. Execution of the arcs labeled with upper- 
case letters on the graphs of Figure 2 is sufficient to ensure 
traversal of all arcs. Data were selected to satisfy path pre- 
dicates for each such arc, predicates which describe constraints 
on the inputs to ensure execution of the arc. The program was 
instrumented with a counter on each labeled arc to count the 
number of arc traversals, thus ensuring after testing that no 
arcs had been missed. 

More stringent criteria could have been applied, but execution 
of all possible control paths was not possible since the program 
has an infinite number of paths. 

2 . Extended Technique 

The method of selecting test data as described above 
was repeated with the additional criterion that each conditional 
branching statement with more than one predicate be executed 
with each possible combination of truth values of the predicates, 
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thus expanding the class of errors that might be detected by 
the tests. Additional path predicates were considered and a 
larger set of test data was selected. 

E. INDEPENDENT SUB -STRUCTURES . 

A method for selecting test cases which is similar to path 
analysis has been suggested in References 27 and 33. As applied 
herein, the technique was to decompose the control flow graph 
of each procedure of a program into independent circuits corre- 
sponding to language constructs and to use these sub -s tructures 
as an aid in identifying control flow paths for testing. The 
cyclomatic number of a single-entry single-exit procedure is 
the maximum number of such sub-structures; these independent 
circuits can be identified by inspection for simple graphs or 
more generally as follows: 

A spanning tree (33) is a connected sub-graph consisting of 
all nodes of a procedure's graph but containing no circuits. Its 
arcs are called branches. There is one independent circuit 
corresponding to each arc of the parent graph not included in 
the spanning tree; these arcs, including an imaginary arc from 
the exit node back to the entry node, are called chords. As 
each chord is added to the spanning tree, the corresponding in- 
dependent circuit can be identified. 

A matrix representation of the circuits was useful in gener- 
ating control paths for dynamic testing from the sub-structures. 
A fundamental circuit matrix (33) was constructed with rows 
corresponding to arcs (chords and branches) ; its entries were 
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0 for arcs not contained in a circuit, 1 for arcs oriented in 
the direction of an assumed circuit flow, and -1 for arcs 
oriented agai-nst the assumed flow. Chords were listed on the 
left of each row, forming a unit matrix because there is a one- 
to-one correspondence between chords and circuits. 

The usefulness of the fundamental circuit matrix was that 
linear combinations of circuits (the rows) having at least one 
arc in common generated control paths useful for testing. Selec 
tion of paths in this manner satisfied a criterion more stringen 
than traversal of each arc at least once, while considerably les 
stringent than traversal of all possible paths. 

In Section E of Chapter IV, the results of the application 
of this technique are discussed. Following the generation of 
the paths to be tested, test data were selected to satisfy the 
path predicates and dynamic testing was conducted. 
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IV. PRESENTATION OF RESULTS 



A. STATIC ANALYSIS 

Prior to the commencement of the experimental methods, 1.0 
man-hours of effort were expended in static analysis of the 
example program. Code was read to check syntax and reachability 
of program fragments, and control flow graphs were examined to 
check for adherence to structured programming constructs and 
to learn the general flow of the program. No exceptions were 
noted in these areas. 

All global and local variables were examined to ensure 
proper declarations and to check the transitions among the states 
of being undefined, defined and not referenced, defined and 
referenced, and an anomalous state (23). No illegal state 
transitions were found; however, two instances of questionable 
programming practice were noted. First, the string array variable 
"cardbuffer" is initialized to contain 80 blank characters in 
the procedure "initialize" (state = defined and not referenced) . 

In a data flow sense, the next action performed on that variable 
is to re-define it in the procedure "read-f-and-^write-'-input^cards , " 
thus transitioning to the anomalous state. Since the variable 
is re-defined before being referenced, the initializing of 
"cardbuffer" in the "initialize" procedure is superfluous. 

Second, all iterative counters in for statements in the example 
program are explicitly declared. Because the Algol-W compiler 
implicitly declares such counters, the effect in the example 
program is to explicitly declare several variables that are 
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subsequently not defined or referenced. Although this is a 
shortcoming in style, the superfluous declarations cause no 
ill effects other than to waste a small amount of storage. 

The verifications performed during static analysis were 
required to ensure satisfaction of several assumptions for the 
experiments in correctness demonstration , particularly that the 
program has no significant data flow anomalies and that the 
program is well structured and procedures do not contain 
statements leading to unexpected side effects. The two in- 
stances of style noted above were not corrected prior to ex- 
perimentation . 

B. PROOF OF CORRECTNESS 

The detailed proof of correctness for the example program 
is presented in Appendix A. The first step in constructing 
the proof was to formalize the output specification of 'the 
program, a task requiring 0.8 man-hours of effort. It was 
desired to prove that at program termination the arrays "begin-*- 
of-'-pal indrome" and "end-<-of^pal indrome" would contain, correspon- 
ding to indices starting from 1, integers representing the 
beginning and ending characters in the string "text" for all 
palindromes in the string, subject to the constraint that 
palindromes fully contained within a larger palindrome would 
not be recorded. A palindrome initially recorded in the arrays 
and subsequently found to be included in a larger one would be 
"deleted" by setting the "end^of-'-palindrome" entry to zero. 
Overlapping palindromes would be recorded. 



60 



The formal statements made for the specification are ("£" 
is an abbreviation for "length*-of+-text" ; "bop" and "eop" are 
abbreviations for the beginning and ending entry arrays; "jx" 
is a counter which is equal to one more than the number of entries 
made in those arrays) : 

Q: V x [ (2<=x<=£ a text (x- 1) =text (x) ) =?> 

3y (y< j x a l < =bop (y) <=x- 1 /n x< = eop (y) <=£) ] 

» 

R: Vx[(3<=x< = £ a text (x-2) = text (x) ) 

3y(y<jx a l<=bop (y) <=x-2 a x<=eop (y) <=£) ] 

S: Vy[(0<y<jx a bop(y)>l a 0<eop(y)<£) ==> 

Ctext(bopCy) -l)=text(eop(y)+l) ) ] 

T: Vy [ (0<y<jx a (eop (y) =0) ) => 

[string (bop (y) , eop (y) ) =ok a bop(y)>=l A eop(y)<=£ 
aVz( (0<z<jx A ~'Cz=y))-==> 

( (bop (z)=bop(y) ) 

a (bop(z) <bop (y) eop (z) <eop (y) ) ) )] 

The assertions Q and R require, respectively, that all 
palindromes of length 2 and length 3 are included within some 
entry in the arrays "bop" and "eop." Due to the symmetry of 
palindromes, all must contrain a palindrome of length 2 or 3 at 
the center; therefore, when conditions Q and R are satisfied, 
all palindromes have at least been detected by the workings of 
the algorithm, even if their total extent has not been recog- 
nized. Condition S requires that any valid entry in the arrays 
"bop" and "eop" represents as long a palindrome as can be 
recognized starting from the length 2 or 3 palindrome at the 
center; symmetry is again relied upon. Finally, condition T 
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requires that all strings represented by valid entries (those 
with non-zero "eop" entry) are in fact palindromes (the notation 
"string(l,2)=ok" is used to indicate that the sub-string starting 
at position 1 in "text" and ending at position 2 is a palindrome) , 
and that no entry in the arrays "bop" and "eop" is included 
with another entry. 

Together the four assertions provided a formal statement 
that could be proved from the semantics of program statements 
and the assumption that the input constraints (see Appendix A) 
have been satisfied. 

Given the output specification to be proven, five procedures 
were determined during static analysis to have no bearing on the 
program's performance of the desired process. Procedures "textl," 
"text2," and "text3," merely print output labels; "b lank^-lines" 
inserts blank lines in the output. Procedure "write-'-al l«-palin- 
dromes," while complex, serves only to print the strings corre- 
sponding to the entries in the previously mentioned arrays. No 
correctness proof other than for termination was supplied for 
these procedures. 

For the remaining significant procedures, Table III presents 
the man-hours of effort expended in constructing their proofs. 

As is discussed in Chapter V, there was a relationship between 
procedure complexity and the time to construct a proof for the 
procedure. The time required to prove procedure "read- ( -and- ! -wr ite-<- 
input-s-cards , " the first somewhat complex procedure proved, was 
distorted by the presence of a significant learning curve. 
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TABLE III 



TIMES TO CONSTRUCT PROOFS 
Task Accomplished or 



Procedure Proved 


Man-Hours 


Formalize output specification 


0 . 8 


"initialize" 


0.8 


Show termination of 5 utilities 


0.6 


"read-*-and-*-wr ite-<-input-*-cards" 


4.2 


"pal indr ome-f-check" 


1.6 


"continue-f-che eking" 


1.8 


"record-f-pal indrome" 


3.5 


"main" 


0.2 


Total 


13'. 5 



C. DISTRIBUTED CORRECTNESS 

The detailed demonstration of correctness of the example 
program using the condition table method and the principle of 
distributed correctness (described in Chapter III) is presented 
in Appendix B. As in the formal proof of correctness, this 
method required formalization of the output specification as 
a first step; the same output assertions were established as 
in the formal proof. The six significant procedures were tested 
by choosing synthetic assertions, test data assertions, and 
generalization assertions, and then executing test data to 
verify the assertions. Table IV presents the man-hours of 
effort expended in demonstrating correctness by this method. 
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TABLE IV 



TIMES TO DEMONSTRATE CORRECTNESS 




Task Accomplished or 




Procedure Shown 


Man-Hours 


Formalize output specification 


0.8 


"initialize" 


0.2 


"read-f-and-f-write-*- input-f-cards 


0.7 


"pal indr ome-f-check" 


0.9 


"continue-«-che eking" 


1.3 


" re co rd-f-pal indrome" 


3.2 


"main" 


0.4 


Total 


7.5 



The test data elements used to verify the test data asser- 
tions in the correctness demonstration are consolidated in 
Table V into one comprehensive set of test cases; the palindromes 
which should be recorded for the given texts are indicated by 
underscoring. The degree to which these test cases satisfied 
the requirements for an ideal test is discussed in a later section. 



TABLE V 

TEST CASES IDENTIFIED BY 
CONDITION TABLE METHOD 



Test 

Number 


Length 
of text 


Text 


Test 

Number 


Length 
of text 


Text 


1 


2 


ab 


13 


4 


aabc 


2 


2 


aa 


14 


4 


aFb a 


3 • 


80 


Note 1 


15 


4 


abbe 


4 


81 


Note 1 


16 


5 


aEFad 


5 


160 


Note 1 


17 


5 


abbed 


6 


240 


Note 1 


18 


5 


aFccb 


7 


256 


Note 1 


19 


5 


ab ccd 


8 


3 


aba 


20 


6 


abeeba 


9 


3 


aab 


21 


6 


ab c cb d 


10 


3 


aFb 


22 


6 


abeede 


11 


4 


abcc 


23 


9 


baaabaaab 


12 


4 


aaaa 









Note 1 - any text which includes overlapping palindromes 
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For purposes of comparison with later sets of test cases, 
it is noted that execution of the above tests required 0.88 
seconds of CPU time. 

D. PATH ANALYSIS 

1 . Basic Technique 

Static analysis of the program identified 21 individual 
decision-to-decision paths in the program control flow graph. 

The program was instrumented with integer counters placed in 
added assignment statements to record the number of traversals 
of each of these arcs (which are identified by upper-case letters 
in Figure 2, Chapter III). The analysis -and instrumentation 
required 0.8 man-hours of effort. 

Path predicates were established and test cases selected to 
force traversal of each arc at least once (0.3 man-hours required). 
For the example program the path predicates were quite simple 
to satisfy. Finally, the test data (shown in Table VI) were 
used in dynamic testing of the program (0.2 man-hours). Table 
VII lists the individual arcs and the number of traversals of 
each which were recorded. No program errors were detected. Each 
arc was traversed at least once, and thus the selected data 
provided at least a "minimally thorough" test of the program 
(22). The total effort involved in the application of this 
method was 1.3 man-hours. The tests required 0.05 seconds of 
CPU time. 
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TABLE VI 



TEST CASES IDENTIFIED 



Test 

Number 

1 

2 

3 



BY PATH ANALYSIS 
Length 

of text Text 

1 

2 xy 

7 baaaaca 



TABLE VII 

ARC TRAVERSALS USING 
PATH ANALYSIS DATA 



J Arc: iABCDE_FGHJKLMNP£RSTUV 



Test 1 
Test 2 
Test 3 



112111 1 1 
117113332115632433 1 



Total 122922343221563243311 



2 . Extended Technique 

Preceding the arcs labeled D, N, P and Q in Figure 2 
are decision statements involving two or more predicates (e.g., 
" if (A and B) then ") . The basic path analysis technique pro- 
vided simply for traversal of each arc following such decisions 
(i.e., "A and B" true, and "A and B" false). A more thorough 
test of a bi-conditional decision would execute the decision 
statement under the four truth combinations for the two predi- 
I cates (A true and B false, A true and B true, A false and B 
true, A false and B false); similarly a tri-conditional decision 
could be executed under the eight truth combinations for the 
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three predicates. 



Analysis of the appropriate path predicates identified 
four additional test cases (Table VIII) which, when added to 
the three cases selected by the basic technique, ensure execution 
of multi-condition decision statements under all (possible) 
combinations of truth values for the decision predicates. Table 
IX presents the arc traversals recorded for the additional tests. 

No program errors were detected. The total additional 
effort to select the additional cases was 0.9 man-hours; 
therefore, the total time to apply the extended path analysis 
method was 2.2 hours. The additional tests required 0.18 
seconds of CPU time, for a total CPU time of 0.23 seconds for 
the extended method. 



TABLE VIII 



TEST CASES IDENTIFIED BY 



EXTENDED PATH ANALYSIS 



Test 

Number 



Length 

of Text Text 



4 

5 

6 
7 



257 



5 

5 



aaa 

baaab 



160 



*Any string of 160 
characters 
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TABLE IX 



ARC TRAVERSALS USING 
EXTENDED PATH ANALYSIS DATA 

l Arc: _ Z _ _A_ _B_ _C_ _D_ _E_ _F_ _G_ _H_ _J 



Test 4 
Test 5 
Test 6 
Test 7 



113 112 1 

115 112 2 12 

1 2 160 2 1 1 158 158 



Total, 

Tests 1-7 2 5 6 177 6 5 8 164 5 162 



j Arc: _K L_ _M_ _N_ _P_ _Q_ _R_ _S_ _T_ _U_ _Y 



Test 4 
Test 5 
Test 6 
Test 7 




1 

1 

1 



Total , 

Tests 1-7: 558 13 366 10 314 



E. INDEPENDENT SUB -STRUCTURES 



The techniques described in Chapter III, Section E, were 
applied to the six significant procedures of the example program 
to identify control paths for testing based on the independent 
language constructs of the procedures. A spanning tree (consis- 
ting of all nodes but containing no circuits) was constructed 
corresponding to each procedure control flow graph presented in 
Figure 2 (Chapter III); the arcs of the spanning tree were 
considered as branches. The remaining arcs of the parent graphs 
were considered to be chords, with a single independent circuit 
or language construct corresponding to each. The fundamental 
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matrices for the six procedures are presented below; the rows 
are labeled with the language construct names of the fundamental 
circuits; the columns are headed with the arc (branches and 
chords) labels. If a fundamental matrix has n rows, the first 
n column labels from the left are the chords and the remaining 
column labels are the branches. The matrix entries have the 
meanings described earlier. 

Procedure "initialize": 

f e a b c d 
10 1110 main-line 

010-101 if-then 



Procedure "read-«-and-*-write-*-input- ( -cards" : 



h 


d 


f 


a 


b 


c 


e 


g 














1 


0 


0 


0 


0 


0 


0 


1 


main- 


1 ine 








0 


1 


0 


0 


0 


1 


0 


0 


while 


-do 










0 


0 


1 


0 


1 


0 


1 


0 


for 












Procedure 


M 


palindrom 


e-<-check" : 












n 


f 


1 


j 


m 


a 


b 


c 


d e 


g 


h 


i 


k 




1 


0 


0 


0 


0 


1 


1 


0 


0 0 


0 


0 


0 


0 


main- line 


0 


1 


0 


0 


0 


0 


0 


0 


1 -1 


0 


0 


0 


0 


if-then 


0 


0 


1 


0 


0 


0 


0 


0 


0 0 


-1 


1 


0 


1 


if-then 


0 


0 


0 


1 


0 


0 


0 


0 


0 0 


0 


0 


1 


-1 


if-then 


0 


0 


0 


0 


1 


0 


0 


1 


0 1 


1 


0 


0 


0 


for 


Pr 


ocedure 


, " 


con 


.tinue*- 


che 


eking" 


: 










j 


f 


g 


a 


b 


c 


d 


e 


h i 












1 


0 


0 


1 


0 


0 


0 


0 


1 1 


main- 


1 ine 




0 


1 


0 


0 


0 


-1 


1 


-1 


0 0 


if- 


then- 


else 




0 


0 


1 


0 


1 


1 


0 


1 


0 0 


whi 


le 


-do 







69 



Procedure "record^-palindrome" : 



n 


d 


h 


•i 


m 


a 


b 


c 


e 


f 


g 


j 


k 


1 




1 


0 


0 


0 


0 


1 


0 


0 


0 


0 


0 


1 


1 


0 


main- line 


0 


1 


0 


0 


0 


0 


0 


1 


-1 


0 


-1 


0 


0 


0 


if- then-else 


0 


0 


1 


0 


0 


0 


0 


0 


0 


1 


-1 


0 


0 


0 


if-then 


0 


0 


0 


1 


0 


0 


1 


0 


1 


0 


1 


0 


0 


0 


for 


0 


0 


0 


0 


1 


0 


0 


0 


0 


0 


0 


0 


-1 


1 


if-then 



Procedure 


"main" : 






g e a b 


c d 


f 




10 11 


0 1 


1 


main- line 


0 10-1 


1 -1 


0 


if- then-else 



The control paths for testing were selected by using the rows 
(fundamental circuits) and all linear combinations of rows having 
one or more branches in common to identify sequences of arcs which 
should be tested. The paths for each procedure that were selected 
in this manner are presented below; paths are identified here in 
a node-to-node format (node numbers correspond to those in Figure 
2 ). 



Procedure "initialize": 

1 - 2-3 

1 - 2 - 4-5 



Procedure "read«-and+-write j -input-'-cards" : 

1 - 2 - 3 - 5 - 2-6 * 

1 - 2 - 3 - 4 - 3 - 5 - 2-6 



Procedure "pal indrome-<-check" : 

1 - 2-10 * 

1 - 2 - 3 - 4 - 5 - 9 - 2-10 

1 - 2 - 3 - 5 - 2 - 9-10 

1 - 2 - 3 - 5 - 6 - 7 - 8 - 9 - 2-10 

1 - 2 - 3 - 5 - 6 - 8 - 9 - 2-10 
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Procedure "continue-'-checking" : 



1-2-7-8 

1-2-3-4-6-2-7-8 

1-2-3-5-6-2-7-8 



Procedure "record-<-palindrome" : 

1-2-8-9-10 * 

1 - 2 - 8-10 

1-2-3-5-7-2-8-10 

1-2-3-4-6-7-2-8-9-10 

1-2-3-4-7-2-8-9-10 

Procedure "main" : 

1-2-3-5-6 

1-2-4-5-6 

Path predicates were established for the control paths 
listed above and test cases were selected to force their 
traversal. The paths above followed by have path predicates 

which cannot be satisfied by any input data; the given execution 
sequence is impossible for any allowable input. The minimal set 
of test cases selected to satisfy the path predicates is presented 
in Table X. Dynamic testing with these test cases revealed no 
program errors; 0.12 seconds of CPU time were required for the 
tests. Table XI describes the allocation of the 2.2 man-hours 
of effort expended in the application of this method. 
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TABLE X 



TEST CASES IDENTIFIED BY 



INDEPENDENT 


SUB -STRUCTURES 


METHOD 


Test 


Length 




Number 


of text 


Text 


1 


1 


_ _ 


2 


2 


xy 


3 


2 


aa 


4 


3 


aba 


5 


3 


abc 


6 


7 


aabbbba 



TABLE XI 

TIMES TO APPLY METHOD OF 

INDEPENDENT SUBSTRUCTURES 

Task Accomplished or 
Procedure Shown 


Man-Hours 


"initialize" 


0.1 


"read-*-and-<-write*-input«-cards" 


0.2 


"palindrome- ( -check" 


0.6 


"continue^-che eking" 


0.3 


" re co rd-f-pal indrome" 


0.7 


"main" 


0.1 


Conduct dynamic tests 


0.2 


Total 


2.2 



For purposes of comparison of the degree of arc coverage of 
tests conducted by this method with that of the path analysis 
tests, the instrumented version of the example program was 
executed with the test cases from Table X; the results are 
given in Table XII. 
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TABLE XII 



ARC TRAVERSALS USING 
INDEPENDENT SUB -STRUCTURES DATA 



| Arc: 


Z 


A 


B 


c 


D 


E 


F 


G 


H 


J 


K 


L 


M 


N 


P 


2 


R 


S 


T 


U 


V 


Test 1 
Test 2 


1 


1 


1 


2 


1 


1 




1 






1 


















1 




Test 3 
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1 
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1 
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Test 6 




1 


1 


7 


1 


1 


4 


2 


2 


3 


1 


2 


4 


6 


3 


2 


7 


3 


3 




1 


Total 
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S 
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5 


5 


5 


7 


3 


4 


5 


2 


4 


8 


3 


2 


7 


S 


3 


2 


3 



F. INTUITIVE TESTS 

The intuitive test data selected prior to conduct of the 
previous experimental demonstrations of correctness were used 
for dynamic testing. No program errors were revealed. For 
purposes of comparison of the degree of coverage with other 
methods, Table XIII presents the results of execution of the 
instrumented program with the intuitive test data listed in 
Table II (Chapter III, Section A). The selection and testing 
of these data required 0.7 man-hours of effort; the tests 
consumed 0.44 seconds of CPU time. 



TABLE XIII 



ARC TRAVERSALS USING 
INTUITIVE DATA 



I 


Arc : 
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A 


B 


C 
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G 


H 


J 


Test 1 






1 


1 


2 


1 


1 


1 








Test 2 
Test 3 




1 


1 


1 


3 


1 


1 




2 


1 




Test 4 
Test 5 




1 


1 


4 


256 


4 


1 


3 


252 


3 


251 


Test 6 






1 


1 


15 


1 


1 




14 




13 


Test 7 






1 


2 


100 


2 


1 


1 


98 




98 


Test 8 






1 


4 


256 


4 


1 


1 


254 




254 


Total , 
Tests 1 


__ 0 
O 


2 


6 


13 


632 


13 


6 


6 


620 


4 


616 
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Test 
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Test 


3 


















Test 
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Test 


5 




1 


14 6 


6 


1 1 


10 


5 1 




Test 


6 




1 
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Test 


7 




1 


49 


1 






1 




Test 


8 




1 


127 


1 






1 




Total 


9 


















Tests 


1 


-8 
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190 6 


10 


1 1 


10 


9 1 


1 



74 



V. CONCLUSIONS AND RECOMMENDATIONS 



A. COMPARISON OF METHODS 
1 . Level of Effort 

Table XIV is a summary of the man-hours of effort required 
for each method of demonstrating the correctness of the example 
program, broken down by procedure for those methods where pro- 
cedures were examined individually. The cyclomatic number and 
number of statements for each procedure are included in the table 
as measures of procedure complexity. The times to apply the 

‘>1. 

verification techniques are to be compared with one another and 
with original program development times of 5.0 hours to design, 

ii 

7.0 hours to code, 4.0 hours to debug, and 5.8 hours to test (21.8 
hours total) . 
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TABLE XIV 



SUMMARY OF TIMES 
TO DEMONSTRATE CORRECTNESS 



1 

Task or 
Procedure 


Cyclomatic 
Number and 
No. of Stmts 


Time (Man-Hours) 
Method 

A B C D 


Per 

E 


Formalize output 
Specification 






0.8 


0.8 






"initialize" 


2 ; 


i 14 


0.8 


0.2 


- - 


0.1 


Show termination 
of utilities 






0.6 


. 


. 




"read-*-and-t-wr ite ..." 


3 


18 


4.2 


0.7 


- 


0.2 


"pal indr ome«-check" 


5 


7 


1.6 


0.9 


- 


0.6 


"continued-checking" 


3 


15 


1.8 


1.3 


- 


0.3 


"r e cor d-f-pal indrome" 


5 


21 


3.5 


3.2 


- 


0.7 


"main" 


2 


6 


0.2 


0.4 




0.1 


Conduct dynamic 
testing 






- 


* 


- 


0.2 


Total 1 3 . 5 ‘7 . 5 

Methods : 

A - Formal proof 

B - Condition table/distributed correctness 


1.3 2.2 


2.2 



C - Basic path analysis 
D - Extended path analysis 
E - Independent sub-structures 

* - Test time included in times for procedures. 



Quite expectedly the two more formalized verification tech- 
niques (proof and condition table method) required considerably 
more effort than any of the other methods, and in fact required 
more hours of effort than were involved in program design (time 
to construct the proof exceeded even the time to design and code). 
As the subsequent discussion of the thoroughness of each method 
indicates, these two methods provide higher confidence in program 
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correctness than the other simpler and more mechanical methods. 

The question becomes whether the increased return from formal 
methodology is worth the cost. The complexity and importance of 
the software, budget constraints, and several other factors come 
to bear on the decision, and the decision should be made separately 
for each software project. 

From a philosophical standpoint at least, ex post facto 
proof of correctness is inefficient because of a great deal of 
duplication of effort. The logical process of constructing the 
proof, in the case of this experiment and in general, requires 
at least as thorough an understanding of the application and of 
the program control structure and data flow as does the design 
and implementation effort. The logical techniques of proof can 
give excellent evidence as to the correctness of programs (but 
not conclusive; see Ref. 15 and others) and are clearly desirable 
for use, but a higher cost effectiveness than that suggested from 
this experiment is required. Possibilities include attempts to 
automate ex post facto proving of correctness or to introduce the 
lgocal techniques in the design and implementation of software. 
These alternatives are major areas of research; brief mention 
is made here. 

Structured programming concepts, advanced language design, 
and formal definition of requirements are examples of software 
engineering efforts to emphasize the use of logical methods in 
the design and implementation of provable programs. Mann has 
discussed the feasibility of using logic techniques to generate 
programs guaranteed to satisfy the output specifications, thus 
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obviating the need for ex post facto verification (26) . It is 
in this area that the greatest promise for correct software is 
to be found. 

Several aspects of the formal proof process may be subject 
to automation. Manna discussed briefly in Reference 26 (pp. 20 3- 
204) progress that has been made in systems to automatically 
generate invariant assertions and verification conditions and 
systems (theorem provers) to prove the verification conditions. 

Both tasks are formidable and it is unlikely that full automation 
can be achieved; yet, partial solutions would be extremely help- 
ful in reducing the tedium involved in the process of formal 
proof. The limitations on automation of the process are succinctly 
stated by Dijkstra (9): 

The distorting spell of speed still seems to 
take its victims. We see automatic theorem 
provers proving toy theorems, we see automatic 
program verifiers verifying toy programs and 
one observes the honest expectation that with 
faster machines with lots of concurrent processing, 
the life-size problems will come within reach as 
well. But, honest as these expectations may be, 
are they justified? I sometimes wonder... 

The level of effort required to apply the condition table 
method of selecting test data in a fashion as nearly reliable 
and valid as possible (according to the theory of testing dis- 
cussed in Chapter II) compares more favorably with the original 
program design effort. If similar relationships exist for large- 
scale applications, the method is likely to be effective at 
reducing the life cycle cost of software as the method appeared 
in these experiments to offer a greater ability to locate errors 
than less formal methods, thus reducing maintenance costs. 
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Evidence of the cost effectiveness of this or similar formalized 
test case selection criteria is required from large-scale appli- 
cations in a commercial environment to be conclusive. 

It is interesting to relate the effort required to apply 
to individual procedures the methods A, B, and E (Table XIV) with 
the complexity measures of these procedures. While the sample 
size of the data collected here is too small for statistical 
significance and the data are distorted by the presence of learning 
curves (e.g., procedure "read- ( -and- ( -write- ( -input' ( -cards" was the 
first procedure with loops proven correct, and several false 
starts were included in the 4.2 hours of effort), there did appear 
to be a relationship between complexity and effort to demonstrate 
correctness. Although the level of effort did not linearly 
relate to the magnitude of either of the measures of complexity 
shown in Table XIV, effort appeared to increase with increasing 
complexity, and the cyclomatic number appeared to be a better 
predictor of effort than did the number of statements. 

2 . Thoroughness of Verification 

As discussed in Section B of Chapter II, the requirement 
for an ideal test according to the theory of testing presented 
in that chapter may be satisfied in 'several ways. Selecting no 
test data and proving that the program is correct (i.e., contains 
no errors) clearly satisfies the criteria for an ideal test. 
Accordingly, on the basis of the proof of correctness constructed 
as part of this experiment it can be stated that the example 
program is correct as written, provided the proof contains no 
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errors and no unwarranted assumptions. That proviso is not easily 
ignored; Reference 15 is only one source of examples of programs 
"proven" correct which in fact contain errors. Nonetheless, the 
proof provides a high degree of confidence in the correctness of 
the example program. 

The several path analysis strategies, including the identi- 
fication of paths for testing by decomposition into independent 
sub-structures, did not include any attempt to show the reliability 
and validity of the test cases selected. Consideration of possible 
errors in the program, particularly in the statements controlling 
control flow, revealed several potential errors that would be 
detected using the test cases of the extended path analysis tech- 
nique (multi -conditions emphasized) but not by one or both of 
the other two path analysis methods. 

For example, if the statement 

while ((ix< = length-*-of-<-text) and 
(buf ferpositionccard limit)) do 

in the procedure "read-<-and-<-wr ite-*-input-<-cards" had the incorrect 
relational operator "buf ferposition<=" vice "<", none of the test 
cases selected by the basic path analysis technique or by sub- 
structure analysis would reveal the error (no string sufficiently 
long) , but test 7 (length 160) of the extended path analysis 
method would reveal the error through a run-time indexing error 
on assigning the 81st character to "text." Similarly, if in 

procedure "record-«-palindrome" the statement 

if ( (first>=begin«-of-<-palindrome (i) ) and 
(last< = end«-of- < -palindrome(i) ) ) then 
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omitted the "or equal" test from the ">=" and "<=" operators, 
the basic and extended path analysis test case 3 ("baaaaca") 
would reveal the error by recording three palindromes (b aaa aca , 
ba aaa ca , and baaaaca) which are included in the larger palindrome 
(b aaaa ca) and should be ignored. The error would not be revealed 
by the test data selected from independent circuit considerations. 

Because there exist potential errors that would not be 
revealed by the path analysis test sets (including the extended 
method set, as will be shown in the next paragraph), the criteria 
as applied in these experiments were not valid and reliable in 
the meaning of testing theory. While the particular errors 
revealed or not revealed in these experiments are peculiar to 
the program under test, selection of test data by any means of 
path analysis other than exhaustive path testing cannot be ex- 
pected to detect all program errors. 

The test cases selected by condition tables were capable of 
revealing all of the errors considered above, including the two 
specific errors mentioned (test cases 4, 5, 6 and 7 for the 
first, test 23 for the second). Additionally, there were po- 
tential errors which could be detected through dynamic testing 
only by the test cases selected by this method. These results 
are peculiar to the specific program under test but are consid- 
ered representative of the capabilities of the several methods. 

(It is not suggested that the condition table method is in 
general capable of revealing all errors.) 

For example, if in procedure "continue^checking" the 
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statement 



while ((first>l) and (last <length-<-of <-text) 
and (palindrome=true) ) do 

mistakenly contained "last<=" vice "last<," test case 3 ("baaa aca 1 ) 
of the path analysis techniques and test 6 ("a abbbba ") of the in- 
dependent circuit method would both erroneously cause traversal 
of the arc "M" (see Figure 2; arc."M" sets palindrome" equal to 
the value "false") during the calls to the procedure with string 
(first, last) being the underscored palindrome, but there would 
be no external effect noticeable to the tester and the error 
(which has potential to cause an indexing error) would go unde- 
tected. However, the condition table for assertion B17-18 (para- 
graph E.l. of Appendix B) would cause the error to be noticed when 
examining the predicates of the assertion as required by the method 
during execution of test element "abb." 

This localization of test effort afforded by using the prin- 
ciple of distributed correctness is one of the most powerful 
aspects of the method as used in this experiment. While the 
localization added to the effort required (full knowledge of the 
program's internal structure was required), it was the localization 
of analysis that enabled some positive statements to be made re- 
garding the validity and reliability of the selected test data. 
While in several cases it was not possible to prove the generali- 
zation assertion for the selected test data assertion, in each 
case a high degree of confidence was established that the test 
data did in fact partition the input domain for the program frag- 
ment under consideration into equivalence classes with respect 
to program operation. 
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From this confidence and the- fact that no input data were 
excluded from selection, it was concluded that the criterion 
for selecting test data as applied to this program was valid 
and "almost reliable." Additional work in identifying theorems 
which can be used in generalizing from specific test data to 
the entire input domain is needed and offers an opportunity for 
a highly reliable testing methodology. 

The error data provided in Table I, from the original program 
development process, was not useful for discriminating among 
the methods applied in verifying the program. Each method 
would detect the presence of the errors described in Table I. 

It is interesting that the set of intuitive test data (Table 
II) selected prior to thorough analysis of the example program 
is capable of revealing all of the errors considered, including 
the "last<=" vice "last<" error in "continued-checking" (a run- 
time indexing error would occur for "text (last+1) " for test case 
8 as a result of that error). However, the method of casual 
or intuitive selection of test data is not in any way desirable; 
the error detection capability in this case is due only to luck 
and the relative simplicity of the program function, and the 
cost-effectiveness penalty in terms of CPU time expended on 
test cases which are in fact not distinguishable can be severe. 

B. SUMMARY OF CONCLUSIONS AND RECOMMENDATIONS 

This section presents a summary of the conclusions drawn in 
the main text of this thesis. 
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1. The need exists for greater relative emphasis on design 
and implementation techniques as compared to verification tech- 
niques (pages 13 and 77-78). 

2. Significant efforts are required in applying the disci- 
pline of software engineering toward refinement or replacement 
of the verification methods now in use (page 14). 

3. The formal proof of correctness and the application of 
the condition table method based on distributed correctness 
required significantly more effort than the path analysis stra- 
tegies (page 76 ) . 

4. There are serious limitations on the feasibility of auto- 
mating the process of formally proving program correctness (page 
78 ) . 

5. There was some positive correlation of the level of 
effort required to demonstrate correctness with the complexity 
of procedures as represented by the cyclomatic number (page. 79) . 

6. The proof of correctness of the example program provides 
a high degree of confidence in the correctness of the program 
(page 80) • 

7. The path analysis strategies as applied in these experi- 
ments did not provide reliable and valid criteria for selecting 
test cases. Selection of test data by any means of path analysis 
other than exhaustive path testing cannot be expected to detect 
all program errors (page 8l)- 

8. The condition table method using the principle of dis- 
tributed correctness afforded a valid and "almost reliable" 
criterion for test case selection (page 33 ). 



84 



9. Additional work in identifying theorems which can be 
used in generalizing from specific test data to the entire 
input domain is needed and offers an opportunity for a highly 
reliable testing methodology (page 83). 

10. Casual or intuitive selection of test data is not in 
any way desirable (page 83) . 
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APPENDIX A 



FORMAL PROOF 

A. ASSUMPTIONS, ABBREVIATIONS, AND NOTATION 

Several assumptions about the example program were made in 
addition to those verified by static analysis and those mentioned 
in Section B of Chapter IV. It was assumed that the host environ- 
ment of the program (compiler and operating system) was error- 
free. All input data read by the program were assumed type com- 
patible with variables - integers for integer variables, valid 
printable characters (including blanks) for string variables. It 
was assumed that the number of characters following the integer 
stating the length of the input character string was equal to 
that integer. The domain of the numerical values in all predi- 
cate formulae in the proof was assumed to be the integers only, 
and only interger division was intended; the operators div and 
rem were used to represent the integer quotient and remainder, 
respectively . 

Because several of the program variable names are verbose, 
the abbreviations listed below were used in the assertions and 
formulae of the proof: 



-l 


length of text 


-At 


cardlimit 


-cb- 


cardbuff er 


-n 


numb e r-*- o f «- inp u t«- c ar ds 


-c 


card-<-counter 


-bp 


bufferposition 


-bop 


begin^-of^-palindrome 


-eop 


end-<-of-*-pal indrome 


-P 


palindrome 
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Figures 3 through 8, shown in the following pages, are 
listings of six program procedures with labeled invariant asser- 
tions inserted for purposes of the proof. Assertions AO and A58 
are the program input and output assertions. Assertions are con- 
tained within braces "{ and in Figures 3 through 8 wherever 

successive labeled assertions follow a program statement, the 
intermediate assertion to be proved at that point is a conjunction 
of those assertions. Frequently assertions contain within the 
braces the names (labels) of earlier assertions; the meaning im- 
plied is a literal replacement of the label with its earlier 
expansion. In the terminology of Section B of Chapter III, the 
proof presented in this appendix is a proof of the invarient 
statement : 

{AO } program {A58} 

This terminology and that for rules of inference (see the same 
section) are used throughout this appendix. 

B. ADDITIONAL RULES OF INFERENCE 

As mentioned in Chapter III, rules of inference similar to 
those in Reference 26 were formulated for iterative for state- 
ments and procedure calls. Those rules are presented here: 

1 . Iterative Rule 

The statement for C:=E step 1_ until L do F is logically 

equivalent to the program fragment: 

{ P } //an assertion 

C:=E //C a counter, E an expression 

LIMIT:=L / / L an expression 

{1} //an assertion 

more: if C>LIMIT then goto fini 

F 77 loop body 
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C: =C+1 
goto more 

fini : 

{q} //an assertion 

Corresponding to this form of the statement, the rule of infer- 
ence is: 

P=*>I, (I a C< = LIMIT } F {I}, I A C>LIMIT =#> Q 
{P} for statement {Q} 

2 . Call Rule 

All procedures in the example program pass parameters by 
value, so that operations on the formal parameters within the 
procedure body do not affect the actual parameters. Global 
variables may however be modified in the procedures. The nota- 
tion p(f,g) represents a procedure p with some formal parameters 
f which operates on some global parameters g; the procedure has 
a body F and input and output assertions Q and R. A call to 
the procedure with actual parameters a is denoted by call p(a). 
S(a:=f) and T(a:=f) are the assertions in the calling program 
located before and after the call, with formal parameter names 
substituted for actual. The rule of inference is: 

S (a : = f) ==> Q, R =$>T(a: = f), {Q} F {R} 

(S) call p (a) {T} 

The rule is essentially a statement that a procedure call is 
proved when an in-line substitution of the procedure body is 
shown to be valid. In showing that R=?T(a:=f), the prover 
must verify that global variables referenced in T but not in 
R are not modified by execution of the procedure body. 
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C. PROCEDURES TEXT1,2,3 



Because these procedures do not contribute to the essential 
program performance (as was determined during static analysis) , 
only a superficial proof of correctness was performed. It was, 
however, necessary to show termination in order to verify that 
program execution would not endlessly loop in one of these non- 
essential procedures. 



1 . 


Input Assertion: {true} i.e., no restriction. 


2. 


Output Assertion: {true}; i.e., no restriction. 


3. 


Verification Condition: 

{true} procedure {true}, or true /\ null true , where 


null is 


a notation for program statements having no significant 


effect . 


Proof of the verification condition is immediate. 


4. 


Termination 

The procedure has only one entry and one exit and con- 



tains no loops; therefore, it terminates. 

D. PROCEDURE BLANK-*- LINES ; TERMINATION OF FOR STATEMENTS 

Similarly, only a superficial proof of this non-essential 
procedure was performed. 



1. 


Input Assertion: {n>0 } . 


2. 


Output Assertion: {true} ; i.e., no restriction. 


3 . 


Verification Condition: {n>0} procedure {true}. 


4. 


Proof 

Regardless of the value of the antecedent, the consequent 


remains 


the logical value true; therefore, the implication 


holds . 
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5. Termination 



Termination is assured if the error exit at the state- 
ment "assert (n>0) " is not taken, and if the for loop following 
terminates. The error exit is taken when n<=0. The input 
assertion guarantees n 0; therefore, the error exit is not taken. 

The for statement loop terminates whenever the value of the 
loop counter exceeds some pre-defined limit. Informally it is 
clear that, given a finite starting value and finite limit for 
the counter and given that the loop body itself terminates (as 
it does in this case - no nested loops) either the loop body is 
not executed at all (starting value exceeds limit) or eventually 
the counter must exceed the limit (since it is incremently by 1 
following each loop execution, by virtue of the "step 1" portion 
of the statement, and no other assignments are made to the counter 
in the loop body), and the loop will terminate. 

More formally, let EXP=LIMIT+1 -COUNTER be a termination 
expression, let N be the set of natural numbers, and let > be 
the usual greater-than relation. Note that N is well-ordered 
by > . In all implementations of a for statement of the type 
described in the iterative rule of inference, if the initial 
value of EXP is zero or not contained in N (i.e., negative), 
then the loop body is not executed and termination is assured. 
Likewise, if the initial value of EXP>=1, the loop body is 
executed, COUNTER is incremented, and the subsequent value of 
EXP is (EXP-1) £ N. Since an infinite decreasing sequence of 
values of EXP £ N is not possible (N is well ordered) , the loop 
must terminate (EXP=0) . 
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An important conclusion can be reached from the above proof 
of termination of the for statement in procedure "blank lines": 
every occurrence of a statement of the type for C:=E step 1 until 
L do_ F terminates provided the program fragment F terminates. 

E. PROCEDURE WRITER-ALL*- PAL INDROMES 

As in the preceding cases, only a superficial proof was 
required for this non-essential procedure (non-essential in terms 
of the palindrome search problem) . 

1. Input Assertion : (true). 

2. Output Assertion : {true}. 

3 . Verification Condition : 

(true) procedure {true}. The proof is immediate. 

4 . Termination 

The procedure has only one entry and one exit. It con- 
tains no loops other than for statements (which have been shown 
to terminate); therefore the procedure terminates. 

F. PROCEDURE INITIALIZE 

Figure 3 is a listing of procedure "initialize" with the 
necessary assertions included. The notation "input(^)" refers 
to the data value in the input stream which will be assigned 
to the program variable "l”. 

1. Input Assertion : Assertion A1 . 

2. Output Assertion : Assertion A2 . 

3. Verification Condition : {Al} procedure {A2}. 

4 . Proof . 

The proof of this verification condition follows directly 
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procedure Initialize; 

comment Initialize all variables, read lengt h— o f— text , write text 1 j 
begin 

A1 • C 2<=lnput( 1)<=256 A c a = 0 3 
text 1 ; 

Jx: = 1 ; 

pa 1 Indro me —counter *• 2 1 ; 
card limit: = 80 ; 

Int f le Id® ize : = 5 ; 
read( length-.o f — text ) ; 

if (( length— o f —text < 2) or ( length— o f — text > 256)) then 
begin 

wite( "Illegal Input : ", 

" length of Input string Is: " , length— o f— text ) ; 

asser t ( f a Ise ) ; 
end ; 

cardbnffer := rt *; 

A2: C 2< = 1< =256 A ca=0 A jx=l A lt = 80 A cb = blank 3 

end initialize; 



FIGURE 3 

PROCEDURE INITIALIZE 
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from the semantic meaning of the assignment statements and read 
statement. Each predicate of the output assertion is just an 
expression of an assignment made in the procedure body, except 
the term "ca=0", which is just a restatement of an input asser- 
tion predicate. The proof variable "ca" is discussed in the 
proof of the next procedure. A series of intermediate assertions 
could have been made, one following each assignment statement, 
to more formally indicate the method of proof. In particular, 
the _if statement has been ignored in the preceding simple 
proof; it is discussed in the termination proof. 

Note that in Algol-W the meaning of an assignment of a 
single character value to a string of length greater than one 
is to pad out the string variable on the right with blanks; thus 
the predicate "cb=blank", following the assignment statement 
"cardbuffer : =" means that "cb" initially contains 80 blanks 

("cb" is an abbreviation for "cardbuffer", a string array of 80 
characters ) . 

5 . Termination 

The procedure is a concatenation of assignment statements, 
a read statement, a call to procedure "textl", and an i^f state- 
ment containing a potential error exit (:the assert statement) . 
Because "textl" terminates, "initialize" will terminate at the 
output assertion provided the error exit is not taken. Since 
assertion A1 ensures that 2<=£<=256, the compound statement 
forming the consequent of the statement cannot be executed; 
thus the error exit cannot be taken, and the procedure does 
terminate . 
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G. P ROCE DURE-*- RE AD-*- AN D-*-WRITE -(-INPUT-*- CARDS 



Figure 4 contains the assertions for this procedure; several 
of the assertions use abbreviations listed earlier in this 
appendix. A proof variable "ca", a variable that is not an 
actual program variable, was used in this proof to represent 
the characters assigned, or the number of characters that had 
been read from the input stream and transferred into the string 
array "text". 

1. Input Assertion : A4 

2. Output Assertion: A15 

3 . Intermediate Assertions : 

A5 through A14. Verification conditions are provided 
for all possible assertion- to- assertion paths in the following 
paragraphs . 

4 . Path A4 to A5 

The verification condition is: 

2<=£< = 256 A ca=0 a. £ t = 80 A cb = blank 
A n= ( (&-1) div &t)+l a ix=l =^> 

2<=£<=256 A ca=0 A £t=80 a ix=l 
a n> = 1 A n= ( (&-1) div 80) +1 

Given the truth of the antecedents, the consequents are shown 
true as follows : 

a. 2< = £< = 256 A ca=0 a £t=80 A ix= 1 : 
these predicates are just a restatement of antecedents which 
have not been affected by the intervening program statements. 
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A4 ; 



A5 : 



A6 • 
A7 : 
A8: 
A9 : 
A10: 



A1 1 : 



A12: 
AI3 : 



A14: 



A 15 5 



procedure read— and— wr 1 te— Input— cards ; 

comment read input cards according to given length— o f— t ext ; 
begin 

C 2< = 1 < = 256 A ca-0 A 1 t - 80 /\ cb = b lank 3 
Integer number— of —Input— cards ; 

number— o f—i nput-cards :=( length— o f_ text - 1) dlv cardllmit x 1: 

lx:=l; comment reset text Index; 

C 2< = 1< -256 A ca = 0 A 1 t = 80 A lx= 1 a n> = 1 A n= ( ( 1- 1 ) d i v80) + 1 3 

for card— counter : = I step 1 

C ( lx— 1 ) rem80=0 =^>c= ( ( lx— 1 ) d 1 v80) + 13 

C 0< = lx— 1< = 1 A ( lx— 1 < 1 c< =n) 3 

C ~( ( lx— 1 ) rem80=0) c = ( ( ix- 1 ) d 1 v80) +2 3 

C ( lx- 1=1 c > n) A ( ( lx— 1 ) rem8O=0 V lx— 1 - 1 ) 3 

C 2< = 1< =256 A ca- lx— 1 A lt = 80A n> = 1 A n= ( ( 1- 1 ) d 1 v80) + 1 3 

until number— o f— 1 npu t—ca rds do 
begin 

wrl te( card— counter ) ; 
wr 1 teon( u 11 ) ; 
readcard ( cardbuf f er ) ; 
wrl teon( cardbuf fer) ; 

buf f erpos 1 t Ion: -0; comment reset Index; 

whl le 

C 0< = bp<=lt 0< = lx— 1 < = 1 ( ix— 1 -bp ) r em80= 0 A 1 0 

cb=str Ing of next 80 or fewer characters 3 

(( lx< - length— o f— text ) and ( buf f erpos 1 1 lon< card 1 imi t ) ) do 
begin 

text( lx) :=cardbuffer(buf ferpos i t lonl 1) ; 

C 2< - 1< =256 A lt = 80 a n > = 1 a n=<( 1-I)dlv80) + 1 
Acb=strlng of 80 characters 3 

C ca= lx A 0< = bp< It A 1 < = lx< - 1 A (lx- 1-bp) rem80= 0 3 
lx: = lx+ 1 ; 

buf f erpos 1 t Ion: = buf f erpos 1 t ion+ 1 ; 

C A12 A 0< = 1 x- 1< = 1 A c a= lx- 1 A [( bp= 80 A ( lx- 1 ) rem80= 0 ) V ix- 1 = 1 ] 3 

end; comment done for all characters oo a card; 

end; comment done for all cards; 

C lx- 1=1 /\. ca- 1 A 2< = 1< = 25 6 A 1 t = 80 3 

end read— and— wr 1 te_ Input— cards t 



FIGURE 4 

PROCEDURE READ^AND^WRITE^INPUTVCARDS 
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b. n= ( (&-1) div80) +1 : 

follows from n= ( (A - 1) di v £t)+l A £t=80. 

c. n>=l: 

n= ( (&-l)div80) +1 ; 
l> = 2 £-l>=l ; 

l-l =1 =$> (&- 1) div80> = 0 ; 
therefore n>=l. 

5 . Path A5 to A6-10 

The verification condition is: 

A5 a c=l A6 a A7 A A8 a A9 A A10 
The verification condition is proved by considering the conse- 
quents one at a time: 

a. (ix-l) rem 8Q = 0 c= ( ( ix - 1) div 80 ) + 1 {A6}: 

from A5 , ix=l; 

ix=l ((ix-l) div 80)+l=0+l=l; 

because c has been set equal to 1, the consequent of the above 
conditional is true, and the conditional is true regardless of 
the truth of the antecedent. 

b. 0<=ix-l<=& {from A7} : 

ix=l ix- 1=0 , and l>=2. 

c. ix-l<& =$> c<=n {from A7} : 

c=l and n>=l, therefore c<=n, and the conditional must hold. 

d. — i ( (ix-1) rem 80 = 0) ==> c= ( ( ix- 1) div80 ) +2 { A8} : 

ix=l ix-l=0; thus (ix-1) rem 80=0 is true; 

so — j( (ix-1) rem80=0) is false, 
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and the conditional is true. 

e. (ix - 1=2, -=£< c>n) a ((ix- 1) rem 80 = 0 v ix-l = 2.) { A9 } 

ix-l=0 and 2-> = 2, so ix-l=2 is false, and the conditional is true, 
and (ix-1) rem 80=0 is true, and therefore the disjunction is true; 
thus, A9 must hold. 

f. ca=ix-l {from A10}: 

ca=0 and ix=l is sufficient for ca=ix-l. 

g. the remainder of assertion A10: 

these predicates are just a restatement of antecedents which 
have not been affected by the intervening statement. 

6. Path A6-10 to All 

The verification condition is: 

A6 /v A7 a A8 a A9 a A10 /\ c<=n a bp = 0 
a cb = string of next 80 or fewer characters =?> All 
Again the consequents (predicates of All) are considered one at 
a time . 

a. 0<=bp<=2t: 

this follows from bp=0 and 2t=80. 

b. (ix-l-bp) rem 80=0 : 
c<=n ^ — i (c>n) ; 

— i (c>n) a (ix-l=2 ^ c>n) — i (ix-l=2,) ; 

“ J (ix- 1=2,) A ( (ix- 1) rem 80 = 0 v ix-l = 2) ==> (ix- 1) rem 80 = 0 ; 
finally, (ix-1) rem 80=0 A bp = 0 (ix-l-bp) rem 80=0 , 
which is that which was to be proved. 

Co The remainder of the predicates: 
these predicates are just a restatement of antecedents which 
have not been affected by the interveining statements. 
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7. Path All to A12-13 



The verification condition is: 

All a ix<=& a bp<£t a text ( ix) =cb (bp | 1) ■=5 > A12 a A13 
The consequents of the verification condition are considered 
one at a time . 

a. ca=ix {from Al3): 

ca=ix-l A text(ix) =cb (bp j 1) is sufficient for ca=ix to be true. 
text(ix) is the ix-th character, and it is assigned a value in 
this program fragment (that it is the proper value is shown 
shortly) . If ix-1 characters have been previously correctly 
assigned to text, and one more character is assigned, then ix 
characters have been assigned when control reaches assertion A13. 
In Algol-W, the string indexed by bp | 1 is a string of length 1 
(i.e., a character) at position bp in the larger string (cb) ; 
the first position is 0, and the 80th is 79. 0<=bp<£t guarantees 

that bp is in range; "cb=string of next 80 or fewer characters" 
ensures that the proper characters are in the buffer, and 
(ix-1- bp) rem 80=0 means that ix and bp+1 (the next character to 
be assigned in text and the next character in the buffer avail- 
able for assignment) always differ by a multiple of 80, which is 
correct when an 80-character buffer is used. So the proper 
character is being assigned on this control flow path. 

b. 0<=bp<&t {from A13}: 

0<=bp< = Jlt. a bp<£t 0<=bp<&t. 

c. l<=ix<=£ {from A13): 

0< = ix-l< = £ a ix< = £ l< = ix< = £. 
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c. l< = ix<=Jl {from A13}: 

0< = ix-l<=2. A ix< = 2, =£?■ l< = ix< = Jl . 

d. A12 and remaining predicate of A13: 

these predicates are just a restatement of antecedents. 

8 . Path A12-13 to All (return to start of loop ) 

The verification condition is: 

A12 A A13 ix:=ix+l; bp:=bp+l {All} 

The verification condition as expressed above is rewritten as 
follows, replacing ix and bp by ix+1 and bp+1 in assertion All 
(as the assignment rule of inference requires): 

A12 a A1 3 

[0<=bp + l< -Jtt a 0< = ix< = 2. A (ix-bp-1) rem 80 = 0 a 2< = £< = 2S6 
/a ca=ix a £t=80 a n> = l a n= ( (£-1) di_v80) + 1 
a cb=string of next 80 or fewer characters] 

The verification condition is once more proved by considering 
the consequents one at a time. 

a. 0<=bp+l<=&t : 

0<=bp =^0<=bp+l; and since only integer arithmetic is permitted, 
bp<&t -=> bp+l< = 2-t . 

b. the remainder of the consequents: 
restatements of predicates of A12 and A13. 

9. Path All to A14 

The verification condition is: 

All a ->(ix< = 2. a bp<£t) A14 

The proof is constructed by showing the consequents of the veri- 
fication condition one at a time. 
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a. [(bp=80 a ( ix- 1) rem 80 = 0) V ix-l=£] : 

— i (ix<=£ /n bp<£t) means that either ix>£ or bp>=&t, or both. 

Consider ix>£ as case 1; 

ix>£ a 0< = ix-l<=£ -=£>■ &<ix<=£+l, 

so ix=£+l and ix-l = £ , in which case the consequent is true. 
Consider bp>=£t as case 2; 
bp> = £t A 0<=bp< = £t => bp = S.t; 

£t=80 a bp=£t =$>bp=80; 
bp=80 (ix-l-bp) rem80= (ix-1) rem80 ; 
since (ix-1 -bp) rem 8Q=Q , then (ix-1) rem 8Q=8Q , 
and the consequent is true. 

So in either case the disjunctive consequent holds. 

b. the remainder of the predicates: 

these predicates are just a restatement of antecedents. 

10 . Path A6-10 to A14 

The verification condition is: 

{ A6 a A7 a A8 a, ASa A 10} F; while C do P {A14} , 
where F represents the statements between A6-10 and the while 
statement, C represents the predicate of the while statement 
and P is the while loop body. The previous proofs of the 
verification conditions for paths A6-10 to All, All to A12-13, 
A12-13 to All, and All to A14 satisfy the requirements of the 
rule of inference for while statements, and therefore the 
verification condition for path A6-10 to A14 is proven. 

11. Path A14 to A6-1Q 

The verification condition after substituting c+1 for 
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c in assertions A6-A9 (as required by assignment rule applicable 
to " for c: = l s tep 1_" which increments c) is: 

A14 =P [ ( (ix-1) rem 80 = 0 c+l=((ix-l) div 80)+l) 

/v 0<=ix-l< = Jl a. (ix-l<fl, =$> c+l<=n) 

A ~~i ((ix-1) rem 80=0) -=$> c+l= ( (ix-l)div80) +2 
A (ix-l=£ c+l>n) a ( (ix- 1) rem 8Q=0 v ix-l = il) a A10] 

The proof of the verification condition is shown for each con- 
sequento 

a. A10 a 0<=ix-l<=& A ( ( ix-1) rem 80=0 v ix-l=£) : 
these predicates are just a restatement of antecedents. 

b. (ix-1) rem 80= 0 =$> c+ 1= ( (ix - 1) div80) +1 : 

In addition to being a counter for the for loop, "c" is a 
count of the number of data cards that have been read, because 
there is exactly one readcard statement in the for loop body. 
ca=ix-l is the number of characters that have been assigned 
from the buffer into the array "text"; each time the loop is 
executed, 80 characters are assigned into "text", except 
that the last time the loop is executed, from 1 to 80 characters 
may be assigned. 

If (ix-1) rem 80=0 , an even multiple (namely (ix-l) div 80) of 80 
characters have been assigned, and loop has been executed that 
number of times as control returns to A6-10; thus, c+1 (the 
new value after the step) is then one more than that number, or 
c+l= ( (ix-1) di_v80) +1 . Therefore the consequent holds. 

c. —i ( ( ix - 1) rem 80=0) => c + l=((ix-l) div 80)+2 : 

The proof for this consequent is similar to the preceding, ex- 
cept that because ( ix-1) rem80 is not equal to zero, less than 
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80 characters have been read when control returns to A6-10, and 
the loop has been executed one time more than in the case above. 
Thus, c+l=((ix-l) div 80)+2; q.e.d. 

d. ix-l<£=?' c + l<=n: 

If ix-l<£, then since 

(ix-l=£ v (ix-1) rem 80=0) (proved above) , 

it must be that (ix-1) rem 80=0 . 

Therefore, from the above proved conditional, 

c+l=((ix-l) div 80+l is true, 

and ix-l<£ -=& ix-l< = l -1 , 

so c+l<=((£-l) div 80)+l. 

Then because ((&-l) div 80)+l=n, c+l<=n. 

e. ix-l=£ ==p>c + l>n: 

There are two possibilities. 

First, assume — t ( ( ix-1) rem 80 = 0 . 

Then c+l= ( ( ix- 1) div80) +2 , 

and c+l>( (ix-1) div80) +1 . 

If ix-l=?,, then ix-l>2,-l and 

(l - 1) div 80 = (ix-1) div SO ; 

therefore c+ !>((£-!) div 80) +1 , thus c + l>n. 

Second, assume (ix-1) rem 80=0 . 

Then c+l= ( (ix-1) div;80) +1 , 
and since £=ix-l, l rem 80=0 
and (£-1) div 80<£ div 80. 

Therefore c+l>((&-l) div 80)+l , thus c+l>n. 

In either case, c+l>n and the consequent is proved. 



102 



12 . Path A6-10 to A15 

The verification condition is: 

A6 A7 /\ A8 a A9 a A10 A c>n -=£> 
ix-l=£ a ca=£ a 2<=£<=256 A £ t = 80 
2< = &< = 256 and £ t = 80 are restatements of predicates contained 
in the antecedent of the verification condition; the remaining 
two predicates are verified as follows: 

a. ix- 1=£ : 

ix-l<£ =5> c< = n is true (an antecedent), so the contrapositive 
is also true: 
c>n ■==> (ix- 1) > = i . 

Since c>n, ix-l>*&. 

Also, 0<=ix-l<=£ (an antecedent), therefore ix-l=£ 

b. ca=l: 

ca = ix-l A ix-l=£ ca=l. 

13. Path A5 to A15 

The verification condition is: 

A5 for statement {A15}. 

The previous proofs of the verification conditions for paths 
A5 to A6-10, A6-10 to A14, A14 to A6-10, and A6-10 to A15 satis- 
fy the requirements of the for rule; therefore the verification 
condition for this path is proved. 

14 . Input Assertion to Output Assertion 

The proof of partial correctness for this procedure 
is completed by concatenation of paths A4 to A5 and A5 to A15. 
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15. Termination 



During the preceding proof of partial correctness, the 
reader should have been convinced that the procedure terminates 
by the relations among ix-1, c, and n, and by those among ix, 
i, bp, and Jit. If not, termination is assured because the program 
has one entry and one exit and is a concatenation of assignment 
statements and a for statement. The for statement terminates 
if its loop body terminates; in this case, the body terminates 
provided the while loop eventually terminates. 

The formality of well-ordering could be applied to show the 
termination of the while statement; however, termination is 
evident since "Jit" is fixed at 80 and "bp" starts from 0 and is 
incremented by one on each execution of the loop body (which 
terminates as it has no loops) . Thus "bp" must eventually exceed 
"Jit" and the while statement must terminate (it may terminate 
earlier if ix=Jl) . 

H. PROCEDURE PAL INDROME-*- CHECK 

Figure 5 contains the assertions for this procedure. 

1. Input Assertion : A17. 

2. Output Assertion : A27-29. 

3. Intermediate Assertions : 

A18 through A26. Verification conditions are provided 
for all possible assertion-to-assertion paths in the following 
paragraphs . 

4. Path A17 to A18-22 

The verification condition is: 
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AIT: 



A18: 
A19 : 

A20: 

A21 : 

A22: 



A23 : 
A24: 



A25: 

A26: 



A2T: 

A28: 

A29: 



procedure pa 1 indrome^check; 

comment find all palindromes within given text string; 
begin 

C 2< = 1< =256 A ca= 1 A Jx= 1 3 

comment scan text from left to right; 
for lx: =2 s tep 1 

C 2< = 1< = 256 A ca= l A jx>0 A 2< = lx< = l+l 3 
C VxC ( 2< =x<= lx~ 1 a text ( x- 1 > = text ( x) ) — > 

3y( y< jx a l<=bop(y)<=x— 1 a x<=eop(y)<=l)] 3 

C VxC ( 3< =x< = lx- 1 a text(x-2) = text(x))^ 

3y< y< jx A 1 < = bop( y) < = x— 2 a x< =eop( y) < = 1 ) ] 3 

C VyC ( 0< y< J x /v bop(y)>lA 0<eop(y)<l)^ 

~( text(bop(y)-l) = text(eop(y) + l) ) 3 3 

C VyC (0<y<jx A eop( y) =0) ) 

[str lng( bop(y) ,eop(y) )=ok A bop(y)> = l a eop( y) < = t 
A\/z( (0<z<JxA ~( z = y ) ) ~=^ 

( bop( z) =bop( y) ) A ( bop( z) < bop( y) -==> eop^zXeop(y)) ) )] J J 

until length-of_text do 

begin 

If text ( lx— 1 ) = text(ix) then cont i nue.c hec k. 1 ng( ( lx— 1) , lx) ; 

C 2< = =256 a ca= 1 a jx>0 a 2 <= U <=1 a A20 a A2 1 A A22 3 

C VxC(2<=x< = lx a text ( x— 1 )= t ext ( x) ) ==> 

3 y( y< J x /v l < -bo p( y) < = x— 1 a x< =eo p( y) < = 1 ) ] 3 

if ix 2 then 

If text( lx— 2) = text( lx) then cont lnue_checklng( ( ix-2> . i x) ; 

C A23 A A24 A A21 A A22 3 
C VxC ( 3< = x< = 1 x A text ( x-2) = text ( x) ) 

3yC y< jx a 1< =bop( y) < =x-2 a x< =eop( y) < = 1 ) ] 3 

end ; 

C 2< = 1< =256 a ca= 1 A j x >0 a A2 1 A A22 3 
C VxC ( 2< =x< = 1 a text ( x- 1 ) = text ( x) ) =>> 

3y(y<jx A 1< =bop( y) < = x— 1 A x< = eop( y)< = 1) ] 3 

C VxC ( 3< = x< = 1 a text(x-2) = text(x) )=> 

3y(y<jx a 1< =bop( y) < =x-2 A x< = eo p( y) < = 1 ) 3 3 

end pal lndrome-check; 



FIGURE 5 

PROCEDURE PALINDROME-CHECK 
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A17 a ix=2 =?> A18 a A19 a A20 a A21 a A22 
Proof is shown by considering the consequents one at a time. 

a. 2<=&<=256 a ca=2. {from A18}: 

These two predicates are a restatement of part of the input 
assertion. Their truth is not modified in this procedure, and 
they are repeated in all intermediate assertions. They will 
not be discussed in the discussion of the remaining verification 
conditions for this procedure. 

b. jx>0 {from A18): 
jx=l jx>0. 

c. 2<=ix<=£+l {from A18): 

(ix=2 a 2< = l ) 2<=ix<=£+l. 

d. A19 : 

No x can satisfy the antecedent 2<=x<=ix-l because ix-l=l; 
therefore the conditional is true. 

e. A20: 

This consequent is similarly true. 

f. A21: 

No integer y can satisfy the antecedent 0<y<jx because jx=l; 
therefore the conditional is true. 

g. A22: 

Similarly. 

5 . Path A18-22 to A27-29 

The verification condition is: 

A18 a A19 a A2 0 a A2 1 a A22 A ix>£ ^>A27 a A28 a A29 
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The consequents are all restatements of the antecedents except 
A28 and A29; proofs of their validity follow: 

a . A2 8 : 

ix< = & +1 a ix>& ■==> ix-l=&. 

Therefore assertion A28 is a restatement of A19 with % replacing 
ix-1 in the first predicate of the antecedent, and the assertion 
holds . 

b. A29 : 

This assertion holds similarly. 

6 . Path A18-22 to A25-24, Case 1 

Case 1 for this path is arrival of control at assertions 
A23-24 after execution of the if statement with true predicates. 
In this case, the verification condition is: 

A1 8 a A19 a A2 0 ^ A21 a A22 a 

ix< = & a text (ix- 1) =text (ix) ==? A23 a A24 
The following condition, deducible from the antecedents of the 
verification condition, becomes the input assertion to procedure 
"continued-checking" whenever the actual parameters "ix-1" and 
"ix" are replaced by the formal parameters "first" and "last": 
2<=&<=256 A. ca=& a jx>0 a I<=ix-1<=&-1 a 2<=ix<=& 

A ix-l<ix a text (ix-1) =text (ix) A A21 a A22 
The output specification of the procedure "continued-checking," 
after replacing "current" by the value "current" was assigned 
at the procedure call in the proof of correctness of that pro- 
cedure, namely the value "ix", is: 
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A21 a A22 a 2<-l <=256 a. ca=£ a jx>0 a 
3y(y< jx a l<=bop (y) < = ix- 1 /\ ix<=eop (y)<=&) 

Given that the procedure "continued-checking" has been proven 
correct (presented in the next section of this appendix) , all 
requirements for the rule of inference for procedure calls have 
been satisfied, and the output assertion of "continued-checking," 
as rewritten above, can be used to show the truth of assertions 
A23-24. In fact, assertion A23 is entirely a restatement of 
either this output assertion or the antecedents of the verifi- 
cation condition. Assertion 19 ensures the validity of assertion 
A24 over the range of x from 2 to ix-1; 

( text (ix- 1) =text ( ix) (an antecedent) 

and ^y (y< jx a l<=bop (y) <=ix-l A ix<=eop (y) <=£) 

(from the output assertion of "continue checking") together 
extend the range of x to ix , and therefore assertion A24 holds. 
Thus the verification condition for this case has been proved. 

7 . Path A18-22 to A23-24, Case 2 

Case 2 is the case when the if statement preceding 
A23-24 is executed with the predicates false; in this case, the 
verification condition is : 

A18 A A19 a A20 a A21 A A22 A 
ix<=& A -» (text (ix- 1) =text (ix) ) =^A23 a A24 
All of the consequents but A24 are a restatement of antecedents; 
A24 is a restatement of A19 with the range of x increased to 
include x=ix, the ix-th value having been checked for compliance 
with the assertion in the current iteration of the for loop. 
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Since the antecedent of the conditional contained in assertion 



A24 is false in this case for x=ix, the conditional is true for 
x=ix, and assertion A24 holds. Thus the verification condition 
is proved. 

8. Path A23-24 to A25-26, Case 1 

This first case occurs whenever ix=2, or 
when — ' (ix=2) and also — ( text ( ix- 2 ) =text (ix) ) ; 
in this case, no call is made to procedure "continue-*-checking" , 
and the verification condition is : 

A23 a A24 A25 a A26 

Assertion A25 is a restatement of antecedents, and assertion A26 
is just assertion A20 with the range of x extended to include 
x=ix. The conditions for this case ensure that for x=ix the 
antecedent of the conditional contained in A26 is false; either 
ix=2 and 3<=x is false or 

— i (text(ix-2)=text(ix) ) . Therefore the conditional is true for 
x=ix and thus assertion A26 holds; the verification condition 
is proved. 

9 . Path A23-24 to A25-26, Case 2 

In this case the call to "continue-<-checking" is executed, 
and the verification condition is: 

A23 A A24 A —»(ix=2) a text ( ix- 2) =text ( ix) 

==? A25 A A26 

Similarly to the proof for the previous path containing a call 
to procedure "continue-'-checking" , it may be shown that the 
antecedents of the verification condition satisfy the procedure's 
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input assertion and that the output assertion, together with 
the antecedents, satisfy assertions A25-26. In assertion A26 
the range for the universal quantifier x is extended to include 
the case x=ix as before. 

10. Path A25-26 to A18-22 

The verification condition is (substituting ix + 1 for 
ix in A18-20 because of the assignment) : 

A25 a A26 =4> A21 ^ A22 a 

2<=£< = 2S6 a ca=£ a j x> 0 a 2< = ix + l<=£ + l 
a Vx[(2<=x< = ix a text (x-1) =text (x) ) — > 

3y(y< jx a l<=bop(y)<=x-l a x< =eop (y)< =£ ) ] 
a ^x[(3<=x<=ix a text (x- 2) =text (x) ) =5> 

3y(y< jx a l<=bop (y)<=x-2 a x< =eop (y)< -i ) ] 

All of the consequents but 2< = ix<=£ + l are restatements of 
antecedents ; 

and 2<=ix<=£ 3< = ix+l< -Z +1 , thus 2< =ix+l< =1 +1 is true and 

the verification condition is proved. 

11. Path A17 to A27-29 

The verification condition is: 

{A17} for statement {A27-29} 

The previous proofs of the verification conditions for paths 
A17 to A18-22, A18-22 to A23-24 to A25-26, A25-26 to A18-22, 
and A18-22 to A27-29 satisfy the requirements of the for rule; 
therefore the verification condition for this path is proved, 
thus completing the proof of partial correctness for this 
procedure . 
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12. Termination 



The procedure has one entry and one exit, and the only 
loop is a for statement, which have been shown to terminate. 
Therefore the procedure terminates. 

I. PROCEDURE CONTINUE^CHECKING 

Figure 6 contains the assertions for this procedure. A 
constant "current" is introduced in the proof and the assertions 
this constant is given the value of "last" at the time of the 
procedure call. 

1. Input Assertion : A30-32. 

2. Output Assertion : A38. 

3 . Intermediate Assertions : 

A33 through A37. Verification conditions are provided 
for all possible assertion- to-assertion paths in the following 
paragraphs . 

4 . Path A30-32 to A33 

The verification condition is: 

A30 A A31 A A32 A p = true -=P A33 
The consequent is a restatement of the antecedents with the 
addition of the predicate "current=last , " as mentioned above. 
Thus proof of the verification condition is immediate. 

5 . Path A33 to A34 

The terminology "s tring ( fi rst , las t) =ok" used in these 
assertions indicates that the substring from text(first) to 
text(last) is a valid palindrome. The verification condition 
for this path is: 
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procedure coat inue -checking (Integer value first, last); 
comment Given first and last as pointers to a palindrome 

of size 2 or 3, this procedure checks whether or not this 
palindrome Is Included In a larger palindrome; 

beg! n 

A30? ( 2< = 1< =256 A ca= 1 A jx>0 A 1 < = f 1 r s t < = 1 - 1 A 2< = 1 a s t < = 1 A f ir?t< las t 
A text( f lrst) = text( last) 1 
A3 1 • C VyC ( 0< y< jx a bop( y) > 1 a 0< eop( y) < 1 ) ^ 

~( text(bop(y) — l) = text(eop(y)+l) ) ] 1 

A32: C VyC (0<y<jx A Meop( y)=0) ) 

Cstrlng( bop(y) ,eop( y) )=ok a bop(y)>=l a eop(y)<=l 
a V z ( (0<z<jx A *-( z= y) ) 

( ~ ( bop( z) =bop( y) ) a ( bop( z) < bop( y) eop( z ) < eop( y) > ) >1 ] 

logical palindrome; 
pa 1 lndrome : = true ; 

A33: ( A30 A A3 1 a A32 a p= true a current= last 1 

whl le 

A34*- C A30 A A3 1 a A32 A current< = last A str ing( first, last) =ok 
a ( p= f a lse ~( text ( f irs t — 1 ) = text ( las t + 1 ) ) ) 1 

((flrst> 1/ and ( 1 as t < le ng t tu_o f — t e x t ) and ( pa 1 i nd rome = tr ue > > do 
beg! n 

if tex t ( f irs t- 1 ) = text( last+1) then 

begin 

comment larger palindrome found; 
f lrs t : = f 1 rs t - 1 ? 

1 as t : = 1 as t+ 1 ; 

A35: C A34 1 

end 

e lse 

begin 

pa 1 lndrome : = false; comment largest palindroire found; 

A36: C A34 ) 

end j 

end ? 

A37 J C A30 A A3 1 A A32 A curren t< = las t A str ing( first, las t / = ok 
a ( f 1 rs t = 1 v last=l 'A ~( text ( f lrs t- 1 ) = text ( las t + 1 )) ) ) 

record— pa 1 indr o roe < first, last) ; 

A38: C A31 A A32 A 2< = 1<=256 A ca= 1 A j x> 0 1 

A^y(y<jxA l<=bop(y)<=cnrrent-l A current<=eop(y)< = 1) J 

end cont Inue-checklng; 



FIGURE 6 

PROCEDURE CONTINUED-CHECKING 
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A33 ^ A34 



The consequents are considered one at a time. 

a. A30 a A31 A A32 : 

these predicates are just a restatement of antecedents. 

b. current<=last : 
follows directly from current=last . 

c. string (first , last) =ok : 

static analysis of the program showed that, for all calls to 
this procedure, either first=last-l or first=last-2 (this 
could have been a predicate of the input assertion) , and this 
fact and text ( firs t) = text (las t) ensures that string (first , last) 
is a palindrome when control reaches assertion A34 from A33. 

d. p=false (text (f irst - 1 ) =text (las t+ 1 ) : 

since p=true, the conditional is true regardless of the truth 
of the consequent. 

6 . Path A54 to A35 

If program control reaches assertion A35, then the 
predicates of the while and if. statements are true and the 
verification condition for this path is (substituting first-1 
and last+1 for first and last in the consequent, due to the 
assignment statements) : 

A34 a first>l a last<£ a p=true 
a text (first-1) =text (last+1) ■=^ 

2<=&<=256 a ca=H a jx>0 a I <= first-1<=&-1 a 2<=last+l<=£ 
A f ir s t - 1 <1 as t+ 1 a text ( first - 1) =text (las t+1 ) a A31 a A32 
A current<=last+l a string (first- 1 , last+1) =ok 
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The consequents of this verification condition are considered 
one at a time. 

a. 2<=2.< = 256 a ca=£ a jx>0: 

these predicates are just a restatement of antecedents; they 
remain valid throughout this procedure and will not be discussed 
during the proof of further verification conditions. 

b. I< = first-1<=2,-1 : 

l< = f irst<=£, - 1 A first>l =>> 1<= f irs t- 1<=£, - 1 . 

c. 2< = last + l< = 2, : 

2< = last<=£ a last<£ 2< = last + l< = 5, . 

d. first-l<last+l: 
follows directly from first<last. 

e. text ( first-1) = text (las t + 1) A31 a A32 : 

these predicates are just a restatement of antecedents. 

f. current<=last+l : 
follows directly from current<=las t . 

g. string (first - 1 , las t+1) =ok : 
string(first,last)=ok A text (first-1) =text (last+1) 

=$> string (first-1 , last+1) =ok . 

This concludes the proof of verification condition. 

7. Path A34 to A36 

If control reaches assertion A36 from A34 , then the 
predicate of the while statement is true, that of the i£_ state- 
ment false, and the verification condition is: 

A34 a first>l A last<£ 

a -i (text ( firs t- 1) =text ( las t + 1) ) a p = false =>>A34 



114 



The consequents are shown one at a time. 

a. p=false =$? — i(text(first-l)=text(last+l)) : 

the antecedent and consequent of this conditional are both true 
(antecedents of the verification condition); therefore, the 
conditional is true. 

b. the remainder of the consequents: 

these predicates are just a restatement of antecedents. 

8 . Paths A35 to A34 and A36 to A34 

Since A35 and A36 are each identical to A34 and since 
there are no program statements on these paths, the verification 
condition is A34 =»> A34 , which must be true. 

9 . Path A34 to A37 

The verification condition is: 

A34 A ~'(first> k l A last<& a p=true) ==> A37 
The consequents are considered one at a time, 
a. [first=l v last=S, 

V (text (first-1) =text (last+1) ) ] : 
from the antecedent (first>l a last<& a p=true) , 

DeMorgan' Rule gives: 
first<=l v" last> = & V p = false. 

Since also first>=& and last<=& , and 

since p=false => (text (firs t- 1) =text (last + 1) , 

the above is equivalent to: 

first = l V last = A V (text (first- 1) =text (last + 1) ) ; 
thus the consequent is shown. 
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b. the remainder of the consequents: 
these predicates are just a restatement of antecedents. 



10 . Path A33 to A37 

The verification condition is: 

{ A3 3 } while statement {A37} 

The previous proofs of the verification conditions for paths 

A33 to A34 , A34 to A35, A34 to A36, A35 to A34, A36 to A34, 

and A34 to A37 are sufficient to show this verification condition. 

11. Path A3 7 to A38 

Assertion A37 satisfies the input assertion to proce- 
dure "record-'-palindrome" (in this case the names first, last 
and current retain the same connotations) . Assertion A38 is 
precisely the output assertion of "record-<-palindrome . " Therefore 
the verification condition for path A37 to A58 is verified by 
the proof of correctness for the called procedure (in the next 
section) . 

12 . Input Assertion to Output Assertion 

The proof of partial correctness for this procedure 
is completed by concatenation of paths A30-32 to A33, A33 to 
A37, and A37 to A38. 

13 . Termination 

Procedure "continued-checking" has one entry, one exit, 
and but one loop, the while statement. Assuming "recordd-pal in- 
drome" terminates (proven elsewhere), this procedure terminates 
if the loop terminates. Clearly the loop body terminates, so 
loop execution will terminate if one of the three conditions: 
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firs.t>l, last<£ , or p = true 

ever takes on a value of false. Since initially first>=l and 
"first" is decremented by 1 on each loop iteration for which "p" 
is not set equal to false (in which case termination would be 
assured), then the well-ordering principle of 'the natural numbers 
requires eventually first<=l (unless the loop terminates sooner) . 
So the procedure terminates. 

J. PROCEDURE RECORD*- PAL INDROME 

Figure 7 contains the assertions for this procedure. 

1. Input Assertion : A39-41. 

2. Output Assertion : A51-52. 

3 . Intermediate Assertions : 

A43 through A48. Verification conditions are provided 
for all possible assertion- to-assertion paths in the following 
paragraphs . 

4. Path A39-41 to A42-44 

The verification condition is (substituting 1 for i 
in assertions A42 and A44 because of the assignment to the 
for loop counter) : 

A39 a A40 a A41 a entry=true 
A39 a A40 A A41 a l<=jx A A43 A 
[ (entry=true a -» (eop(O) =0) ) Vz[0<z<j'=^> 

( — i (bop ( z) = f irs t) A (bop ( z) < firs t eop (z) <last) ) ] ] 

The consequents are considered one at a time, 
a. A39 A A40 A A41 : 

these predicates are just a restatement of antecedents. 
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b . 1 < = j x : 

follows directly from jx>0. 

c. A43: 

since entry=true, the antecedent of the conditional is false 
and the conditional is true. 

d„ the remaining complex predicate: 
since there is no integar z satisfying 0<z<i, the consequent 
of the antecedent of this predicate is true, and the conditional 
is shown; thus, the final consequent of the verification con- 
dition is proved. 

5. Path A42-44 to A45-46 

In the event control passes to assertion A45-46 from 
A42-44, the predicate of the intervening i_f statement is true 
and the verification condition is: 

A42 a A43 a A44 a i<=jx-l A f irst>=bop (i) 

A last< = eop(i) a entry =false =>A45 a A46 
Proof is by considering the consequents one at a time. 

a. A39 a A40 A A41 (from A45 } : 

these predicates are just a restatement of antecedents. 

b. i<=jx-l (from A45): 

this predicate is a restatement of the antecedent resulting from 
the test on the loop counter. 

c. entry=false = 3y(y<=jx a l<=bop (y) <=current-l 

a current<=eop (y) <~Z) {A43}: 

entry=false is true; thus it must be shown that there exists 
a value for y such that the predicates following the "existential" 
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A39: 



A40: 
A41 : 



A42: 

A43: 

A44: 



A45 : 
A46 : 



A47: 



A48: 



procedure record.pal indrome (integer value first, last) ; 
comment Record only max length palindromes. Flag* previously 

recorded palindromes If they are included in the palindrome 
specified by first and last. 

jx was initialized to 1. After completion jx points to the 
next entry in begin-of-pa 1 indrome and end_of_pa i in lrnic^ ; 

begi n 

( 2< - 1< =256 A ca= 1 A jz>0 A i< = f irs t< = 1-1 A 2< = 1 as t< = 1 A f irst< last 
A current < = las t A str ing( first, las t ) =o k 

A(flrst=l v' 1 aa t = l v' text( first-i) = text( last+l) )) 1 

C VyC (0<y< jx a bop( y) > l A 0< eop( yX i ) z =$ > 
te xt ( bop( y) - i ) = tex t ( eop( y) + 1 ) ) ] ) 

C Vy[ (0<y<Jx A ~< eopt' y) =0) ) ==> 

[str ing( bop(y) ,eop(y) )=ot A bop(y)>=l A eop( y) < = i 
a Vz( (0<z< jx a ~(z = y))=v> 

(^( bop(z)=bop( y) ) a (bop(z)< bop(y) =£> eop(z)<eop( y) ) ) )] ] ) 

integer i; comment local counter; 

logical entry; 
entry: = true; 
for 1 : = 1 s te p 1 

C A39 a A40 a A41 a 1<=jx ) 

C entry= fa lse ==>3y(y<=jx A 1< =bop( y) < =current- 1 a current< -eop< y)< - l) ) 
C ( entry 5 true A eo p( i— i)=0)) 

VzC0<z<i ■— £»* (^( bop(z) = f irst) A ( bop( z) < f lrs t eep(z)< last) ) ] ) 

unt 1 1 jx— 1 do 
begin 

if ( ( f irs t> = begi n_o f . pa 1 1 ndrome ( i ) ) 

and ( las t< = end. o f .pa 1 indrome (i))) then 
begin 

comment Palindrome is entirely included in a previously 
recorded palindrome. No entry required- 
entry: -fa lse ? 

C A39 /s A40 a A41 a l<=jx-l A A43 ) 

C (entry=true A ~(eop( i)=0)) 

Vz[0<z<= 1 (’ s '(bop(z) = firet) A (bop(z)<first eopizK last) ) ] ) 

end 

e lse 

begin 

if (( begi n_o f — pa i indrome ( i ) >= first) 

and ( end— o f .pa 1 indrome ( i ) < = last)) then 
begin 

end.o f.pa 1 indrome ( i ) : = 0 ; 
comment flag smaller palindrome; 
end ; 

C A45 a A46 ) 
end ; 

C A45 A A46 3 

end; comment All previously recorded palindromes 

compared with last input; 
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A49: C A39 A A40 a A41 a A43 } 

A50: C (entry 2 true A eop( jx>=0) ) ^ 

^zfO<z< jx =^>( **( bop( z) s f irs t ) a (bop(z>< first =^> eop(zM last))] ) 

If entry = true then 
begin 

comment larger than all previous or overlapping or disjoint? 

begin_o f — pa 1 1 ndroine (jx) : = f irs t ; 

end— o f — pa 1 Indrorae ( Jx) : = last; 

jx: =jx+ 1 ? 

end ; 

A51: C A40 A A41 A 2< = 1<=256 a. ca= 1 A jx>0 1 

A52: C 3y(y<j3C A 1< = bop( y) < =current- 1 a curr ent< =eop( y) < = l ) 1 

end record-pal indrone; 
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quantifier hold. 

It is proposed that y=i will satisfy those conditions. 

Since i<=jx-l, i<jx holds. 
i<jx a A41 -=$> bop(i)> = l; 

current< = last a first<last ==> current-l< = f irst ; 

current-l<=f irst a bop (i) <=first => bop (i) <=current-l ; 

therefore 1 <=bop ( i) <=curr ent - 1 holds. 

current< = last a last< = eop(i) =$> curr ent < = eop ( i) ; 

i<jx a. A41 =^> eop(i)< = £; 

so current<=eop (i) <=i holds. 

Therefore, the necessary predicates are all true when y is 
chosen equal to i; this consequent of the verification condition 
is proved. 

d. A46: 

since entry=false is an antecedent of the verification condition, 
entry=true is false and the conditional which is assertion A46 
is true. 

6 . Path A42-44 to A47, Case 1 

Control can pass to assertion A47 from A42-44 either by 
executing the compound statement with the comment "flag smaller 
palindrome" or by failing to execute that compound statement 
when the predicate of the preceding i_f is false. For case 1, 
the case where the predicate is false, the verification condition 
is : 

A42 A A43 A A44 a i<=jx-l A 
(f irst>=bop ( i) a last<=eop(i) ) A 
~ > (bop ( i) > = f irst a eop (i) < = las t) 
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— > A4 7 

All o£ the consequents contained in A47= A45 a {A46 } except 
A46 are restatements of the antecedents. 

a. (entry=true a — ' (eop (i) =0) ) => 

Vz [0<z<-i C ~ > (bop (z) =f irst) a 
( bop ( z) <first =>> eop ( z) clast) ) ] {A46} : 

If entry=false, the conditional is true without further proof. 

If entry=true a —\ (eop (i) =0) , the antecedent of the verification 
condition provides that the generalization on z is true for 
0<z<i; if it is shown to hold for z = i, then it is true for 
0<z<=i and this consequent of the verification condition is 
proved . 

Either bop(i)=first or bop (i) <first . 

Suppose bop ( i) =f irst ; 

then either eop(i)<=last or las t< = eop ( i) , 

and then one of f irst>=bop ( i) a last<=eop (i) , 

or bop (i) >=first a eop (i) <=last , must be true. 

But the antecedent of this verification 
condition indicates both are false; 
therefore —> (bop (i) “first . 

Now suppose bop ( i) <f irst ; 

then first>=bop (i) is true, and 

from “’(first>=bop (i) A last<=eop (i) ) , 

it is shown that last<=eop(i) must be false. 

Thus bop(i)<first =5> eop ( i) <last , and 
the generalization on z holds for 0<z<=i; 
therefore this consequent is true. 
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7 . Path A42-44 to A47, Case 2 



For case 2, the case where the predicate of the if 
statement immediately preceding A47 is true, the verification 
condition is: 

A42 a A43 a A44 A i<=jx-l A 
bop (i) > = f irst a eop (i)=0 =>>A47 

All of the consequents contained in A47= (A45 a A46 } except 
A46 are restatements of the antecedents. 

a. (entry=true A — < (eop ( i) =0) ) =$> 

Vz[0<z< = i ( -i (bop (z) =first) a 
( bop ( z) <f irst => eop ( z) < last) ) ] { A46 h 

since eop(i)=0, the antecedent of this conditional is false, 
and the conditional is true; this completes the proof of the 
verification .condition for this path. 

8 . Path A45-46 to A48 and Path A47 to A48 

There are no program fragments on these paths, so the 
verification conditions are trivially true; they are: 

A45 a A46 A45 a A46 

9. Path A48 to A42-44 

The verification condition is: 

A48 ■==? A39 A A40 A A41 A i + l<=jx 
a A43 A (entry=true A (eop (i) =0) ) ==> 

Vz[0<z< = i + 1 ( ~~ l (bop (z) =f irst) 

A (bop (z) <f irst =$> eop (z) clast) ) ] 

Proof is shown by considering the consequents one at a time. 
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a. A39 a A40 a A41 : 

these predicates are just a restatement of antecedents. 

b. i+l< = jx:' 
i<= j x- 1 ==? i + l<=jx. 

c . A4 3 : 

this predicate is just a restatement of an antecedent. 

d. (entry=true A i (eop (i) =0) ) 

Vz[0<z< = i+1 ( —i (bop ( z) =f irst) 

a (bop ( z) < firs t =$> eop (z) <last) ) ] : 

from A46 it is known that the generalization on z is valid 
over the range 0<z<=i, which is equivalent to the range in this 
consequent, namely 0<z<i+l; therefore this consequent holds. 
Thus, the verification condition for this path is proved. 

10. Path A42-44 to A-49-50 

The verification condition is: 

A42 a A43 a A44 a i>jx-l A49 A A50 
The consequents are considered one at a time. 

a. A49 : 

This predicate is a restatement of antecedents of the verifi- 
cation condition and thus is true. 

b. (entry=true A - \ (eop ( jx) =0) ) 

Vz[0<z< = jx =4> ( (bop ( z) =f irst) a 

(bop ( z) < first => eop (z) <last) ) ] {A50} : 

i>jx-l a i< = jx ==? i=jx. 

Therefore, this consequent is just a restatement of an antece- 
dent with jx=i replacing i. » 
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11. Path A39-41 to A49-50 



The verification condition is: 

(A39-41} for statement {A49-50} 

The previous proofs of the verification conditions for paths 
A39-40 to A42-44 , A42-44 to A45-46 to A48, A42-44 to A47 to A48, 
A48 to A42-44, and A42-44 to A48 satisfy the requirements of 
the for rule; therefore, the verification condition for this 
path is proved. 

12 . Path A49-50 to A51-52, Case 1 

Case 1 is the case where entry=false and the compound 
statement intervening is not executed. The verification con- 
dition in this case is: 

A49 a A50 a entry=false ==> A51 a A52 
Consider the consequents one at a time. 

a. A51: 

The predicates of this consequent are restatements of given 
predicates . 

b. A52 : 

entry=false a A43 ^^A52 (A43 is one of the predicates con- 

tained in assertion A49) . 

13 . Path A49-50 to A51-52, Case 2 

In this case, entry=true and the compound statement 
intervening is executed. The verification condition (with 
jx+1 replacing jx in A51-52) is: 
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A49 a A50 a entry=true a bop ( j x) =f ir st 
a eop ( jx) =last -=^? 

■£ 2< = &< = 256 a ca=& A jx+l>0 a 
V y[(0<y<jx+1 A bop(y)>l a 0<eop (y) < A) -^> 

— ' (text (bop (y) - 1) =text (eop (y) +1) ) ] a 
^y [ (0<y<jx+l A (eop (y) =0) ) =i> 

[s tr ing (bop (y) , eop(y))=ok A bop(y)> = l A eop(y)< = £ 

A Vz( (0<z<jx+l a ~ >(z=y)) 

^ ( -i (bop(z)=bop (y)) A 
(bop (z) <bop (y) eop(z) <eop(y) )) )] ] A 

3y (y< jx+1 A l<=bop (y) <=current - 1 A current<=eop (y) < = 2, ) 1- 
The consequents of this verification condition are considered 
one at a time. 

a. 2<=£<=256 a ca=l a jx+l>0: 

these predicates are just a restatement of antecedents. 

b. ^y[(0<y<jx+l a bop(y)>l A 0<eop (y) <£) 

~~ i (text (bop (y) -1) = text (eop(y)+l))] : 

the antecedent A40 (contained within assertion A49) establishes 
the generalization on y for 0<y<jx. If the statement is true 
for y=jx as well, then this consequent is proved. The ante- 
cedents of the verification condition allow the generalization 
statement for y=jx to be written as: 

(first>l A 0<last<&) ' (text (firs t- 1) =text (last + 1) ) ; 

from the input assertion of this procedure it is known that 
(first=l ^ last= l v/ (text (first - 1) =text (las t + 1 ))) ; 

the generalization statement for y=jx has an antecedent which 
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negates the first two predicates of this disjunction; there- 
fore the third predicate, which is also the consequent of the 
generalization statement for y=jx, must be true. Thus this 
consequent of the verification condition is proved, 
c. Vy[ (0<y<jx+l a -v (eop(y) =0) ) =^> 

[s tr ing (bop (y) , eop (y) ) =ok a bop(y)>=l 
a eop(y)<=£ a V Z ( (0<z<jx+l A — v(z=y)) 

(— > (bop(z)=bop(y) ) 

a (bop ( z) <bop (y) ~> eop (z) <eop (y) ) ) )] ] : 

The antecedent A41 (contained within A49) establishes the 
generalization on y for 0<y<jx. If the generalization statement 
is demonstrated true for y=jx, then this consequent holds. For 
the case y=jx, the conditional which must be proved is: 

~ '(last=0) ==> [string (first , las t) =ok a first> = l 
A last<= l a Vz ( (0<z<jx+l A -i(z = jx)) "=^> ( -a (bop ( z) =f irst) 

A (bop ( z) <f irs t =$> eop ( z) < last) ) )] 

The antecedent of the above conditional is clearly true; if 
the several consequential predicates are true, then the veri- 
fication condition consequent in question is proved. The first 
3 predicates follow from the input assertion. The fourth 
predicate, the generalization on z, has already been shown to 
be true for the range 0<z<jx 
(from entry=true A — i (eop(jx)=0) a A50) ; 

further, if z=jx then (z=jx) is false and the conditional 
which is the fourth predicate is true. 

This completes the proof for this consequent of the verification 
condition. 
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d. 3y (y<jx+l a l<=bop (y) <=current- 1 
a current<=eop (y ) <=£) : 

It is proposed that y=jx will satisfy this existential statement. 
jx<jx+l; 

bop (j x) =f irst a l<=f irst<=£-l a firstdast 
a current< = last a last<=£ 
l<=bop ( j x) < = current - 1 ; 

eop(jx)=last a current<= las t A last<=£ => 
current<=eop ( j x) < = £ ; 

so y=jx satisfies the existential statement, and this last 
consequent of the verification condition is shown. The veri- 
fication conditions for both cases on path A49-50 to A51-52 
have been proved. 

14 . Input Assertion to Output Assertion 

The proof of partial correctness for this procedure 
is completed by concatenation of paths A39-41 to A49-50 and 
A49-50 to A51-52. 

15 . Termination 

The procedure has one entry and one exit, the only 
loop is a for statement; therefore, the procedure terminates. 

K. PROCEDURE MAIN 

Figure 8 contains the assertions for the main body of the 
example program. 

1. Input Assertion : AO. 
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A0 : 

A3: 

A16: 

A53: 

A54: 

A55 : 

A56: 

A57: 



A58: 



comment main; 

C 2< = inpu t ( 1 ) < =256 A ca = 0 5 
initial ize ; 

C 2< 3 i< =256 A ca = 0 A j x= 1 A 1 t = 80 A cb = b lank ) 

read—and— wr i te-lnput-cards i 

£ 2< = 1< =256 A ca= i A jx= 1 ) 

pa 1 indro me— check; 

C 2< = 1<=256 A ca= 1 A J x> 0 ) 
t Yx£(2<=x< = l A text ( x- i ) = text ( x) ) 

By(y< jx a i< = bop ( y) < = x— 1 a x< = eop( y) < = 1 ) ] ) 

C VxC ( 3< = x< = i a tex t < x-2) = t ext ( x) ) 

3y(y<jx a 1< = bop( y ) < = x-2 a x< =eop( y) < = 1 ) ] ) 

C Vy£ (0<y<jx A bop(y)>l a 0<eop(y)<l) 

~( text ( bop( y) — 1 ) = text ( eop( y) +■ 1 ) ) ] ) 

t Vy£ (0<y<jx A eop( y) = 0) )— > 

[ s tring( bop( y) , eop( y) ) = ok. a bop(y)>=l A eop( y) < = 1 
AV' Z ( ( 0< Z< J X A z = y) ) 

( ~( bop( z ) = bop( y) ) A ( bop( z) < bop( y) =£? eop(z)<eop^ y) ) > )] ] J 

If Jx=l then text3 

else vir 1 te— a 1 1—pa 1 1 ndromes : 

t A53 A A54 A A55 A A56 A A57 1 

end . 



FIGURE 8 

PROCEDURE MAIN 
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2. Output Assertion : A5 8 . 

3. Intermediate Assertions: 



The intermediate assertions are assertions A3, A16, and 
A53-57. They are precisely the input and/or output assertions 
of the procedure calls they precede and/or follow. The veri- 
fication condition path for assertion AO to A53-57 is proved 
by repeated application of the rule of inference for procedure 
calls, and then by concatenation. The verification condition 
for path A53-57 to A5 8 is simply: 

{A53-57} non-significant statement {A53-57} , 
because the intervening i_f statement merely prints the results 
which have already been proven correct; its proof is immediate. 

4 . Termination 

All of the procedures called from this main body have 
been shown to terminate; this program has one entry, one exit 
and no loops; therefore, it terminates. This completes the 
proof of total correctness of the example program. 
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APPENDIX B 



APPLICATION OF DISTRIBUTED 
CORRECTNESS TECHNIQUES 

A. ASSUMPTIONS, ABBREVIATIONS, AND NOTATION 

In addition to the assumptions about the example program 
verified by static analysis (Chapter IV, Section A), it was 
further assumed that all input data read by the program were 
type compatible with variables and that the correct number of 
input characters were present in the input data stream. Integer 
arithmetic was also assumed. Because actual dynamic testing 
was involved, assumptions that the operating system and compiler 
operated correctly were at least partially verified during 
testing. 

Because several of the program variable names are verbose, 
the abbreviations listed below were used in presenting the 
assertions and their verification: 



-i 


length- ! -of- f -text 


-it 


cardl imit 


-cb 


cardbuffer 


-n 


number-«-of 4 -input-<-cards 


-c 


card-^-counter 


-bp 


bufferposition 


-bop 


begin-*-of-<-palindrome 


-eop 


end-<-o f«-p a 1 indrome 


-P 


palindrome 



Figures 9 through 12 are listings of four program procedures 
with labeled synthetic assertions inserted to aid the discussion 
of the correctness demonstration. Assertions BO and B29-33 are 
the input and output specifications, respectively. Assertions 
are contained within braces " { }," and in Figures 9 through 12 
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wherever successive labeled assertions follow a program state- 
ment, the intended synthetic assertion for that point is a con- 
junction of those assertions. Frequently assertions contain 
within the braces the names (labels) of other assertions; the 
meaning implied is a literal replacement of the label with its 
expansion. 

Condition tables in the following sections list on their 
left the several predicates which were considered to partition 
the input domain of the given program fragments. The columns 
to the right of the predicates list the conceivable combinations 
of truth values for the several predicates. Corresponding to 
each column, a test data element was selected to verify program 
operation for each composite predicate (conjunction of the truth 
value entries in each column) . The following entries were used 
in the columns: 



y 




Yes , or true . 




n 




No, or false. 




- 




Don't care; either true 


or false. 


(y) 




Required to be true by the value for 
another entry in the same column. 


(n) 


• 


Similar to (y) , except 


false . 



B. UTILITY PROCEDURES 

The procedures "textl," "text2," "text3," "b lank^lines , " 
and "write-i-all-i-palindromes" do not affect program performance 
of the output specification. (They effect the neat printing 
of the results obtained in the significant procedures.) As in 
the presentation of the formal proof for the example program, 
these procedures will not be examined here. However, it should 
be noted that because the method reported in this appendix 
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involved actual program execution, a side effect of the tests 
performed was to verify the performance of these non-essential 
procedures . 

C. PROCEDURE MAIN 

The methodology using the principle of distributed correct- 
ness and the condition table method for selecting test data 
(where needed) was first applied to the main body of the example 
program; procedure calls were treated either as an in-line ex- 
pansion of code or as program statements whose semantic meaning 
was defined by the input and output assertions of the called pro- 
cedure. It was assumed that the input assertion BO is satisfied 
when program execution begins. Figure 9 contains the synthesized 
assertions for this procedure. 

1 . Synthesized Assertion Bl : 

2<=£<=256 a j x= 1 a £t=80 A cb = blank 

a. Test Data Assertion and Verification 

The test data assertion is that for £=2 and for any 
corresponding character string (of length 2) , the synthesized 
assertion is valid. Verification was obtained by executing the 
program statement "initialize;" preceeding assertion Bl with 
input data £=2. 

b. Generalization Assertion and Verification 

The generalization assertion is that for any input 
data satisfying the input assertion BO, the same result as above 
will be obtained. Verification is made by static analysis of 
procedure "initialize" - the assignments satisfying Bl are 
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c o mrne n t main; 



B0: C 2< = 1< =256 } 

ini 1 1 a 1 lze ; 

Bis C 2< 5 1< =256 A jx= 1 A It = 80 A cb= blank 3 

read— and— wr i te— Input— cards ; 

B5 •* { 2< = 1< =256 a ca=l a jx= 1 3 

pa 1 indrome— check; 

if jx= 1 then text3 

else wr 1 te_a 1 1— pa 1 Indromes ; 

B29: C 2< = 1< =256 A ca= 1 A jx>0 3 

B30: C Vxt (2< =x< - 1 A text ( x- 1 ) = text ( x) ) 

3y(y<jx A 1< = bo p( y) < = x- 1 A = eop( y) < = 1 ) 3 3 

B3 1 : C Vxi ( 3< = x< - 1 a text ( x-2) = text ( x) )— > 

By( y< jx a l<=bop(y)<=x-2 a x< - eop( y)< = 1) 1 ) 

B32 • C Vy[ ( 0< y< jx A bop( y) > 1 A 0<eop(y)<l) ^ 
text ( bop( y) — 1 ) 3 text < eop( y) + 1 ) ) ] 3 

B33: C Vyt ( 0< y< j x A eop( y)=0) )^> 

[string(bop(y) ,eop(y))=ok a bop(y)> = l A eop( y) < = 1 
A^z( (0<z<jx a ~(z = y))=^ 

( bop( z) = bop( y) ) /\ ( bop( z) < bop( y) -=$> eop( z ) < eop< y) ) ) )] ] } 



end . 



FIGURE 9 

PROCEDURE MAIN 
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executed unconditionally. 



c. Proof of Synthesized Assertion 

The synthesized assertion follows directly from 
the test data and generalization assertions. Note that the 
procedure call "initialize;" was treated as an in-line sub- 
stitution of code. The proof of B1 amounted to a demonstration 
of correctness of the procedure "initialize." 

2 . Synthesized Assertion B5 : 

2< = £< = 256 A ca=i A j x=l 

The control path from assertion B1 to B5 contains only 
a procedure call to "read-*-and-*-write-f-input-<-cards" ; assertion B5 
is proved by showing that it is equivalent to the output speci- 
fication of the procedure. 

Let assertion B2 be identical to'Bl, and let it be the 
input assertion for procedure "read-*-and-‘-write-<-input+-cards" (see 
Figure 4 in Appendix A) ; clearly B2 holds since B1 precede the 
procedure call and has been shown true. Examination of the 
procedure reveals that the predicates 2<=£<=256 and jx=l are 
not modified in its execution; only the predicate ca=£ (which 
as before means that "Z” characters have been properly read 
from the input stream and assigned to the string variable "text" 
in the proper position) remains to be shown. This will be 
done by verification of the output assertion for the procedure 
called. 

a. Synthesized Assertion B3: 

Let B3 be an assertion inserted following the 
first statement in "r ead-»- an d-f-write-*- input-beards" 
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(n : = ((£- 1) div £t)+l;). The assertion is that: 



"n" is the correct number of 
input cards for the characters 



in a string of 


length 








The test data assertion 


for B3 


was 


determined us 


following condition table to 


divide 


the 


input 


domain 


equivalence classes : 










Predicate 










2 < = £< = 80 


y 


(n) 


(n) 


(n) 


81<=£<=160 


(n) 


y 


(n) 


(n) 


161<=£<=240 


(n) 


(n) 


y 


(n) 


241<=£<=256 


(n) 


(n) 


(n) 


y 


Test data ( £) 


2 


81 


240 


256 


Correct value (n) 


1 


2 


3 


4 



The test data assertion (i.e., that the program will execute 
properly for the test data elements identified in the preceding 
table) was verified by execution of the program to assertion 
B3 with the four test data values of and checking for the 

assignment of the correct value to "n". 

The generalization assertion at B3 is that n is totally 
determined by the four predicates on "it" given in the condition 
table; from the program statement "n :=((£- 1) div Jtt)+1" and the 
predicate Jtt=80 it is apparent that this is so. 

The proof of the synthesized assertion B3 follows directly 
from the test data and generalization assertions and Theorem 2.1 
of Reference 14 (the theorem states that if two functions on 
the same domain D are totally determined by the same predicates. 
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then those predicates partition D into equivalence classes for 
testing purposes). Theorem 2.1 applies in this case as the 
program performance (first function) and the assignment algorithm 
(second function) are both totally determined by the four pre- 
dicates on 

b. Synthesized Assertion B4 : 

Let B4 be inserted following the last statement in 
procedure "read^and^wr ite-f- input-*- cards" (i.e., the output 
assertion for the procedure). The assertion is: 

ix=&+l a ca=& 

The test data assertion for B4 was determined using 
the following condition table to divide the input domain into 
equivalence classes: 



Predicate 



2< = £< 80 


y 


n 


n 


n 


2<=&<=256 a l rem80=0 


(n) 


y 


y 


n 


80<£<=256 


(n) 


n 


y 


(y) 


n=l 


(y) 


(y) 


(n) 


(n) 


n> 1 


(n) 


(n) 


(y) 


(y) 


Test data ( 2,) * 


2 


80 


160 


81 


Correct value (ix) 


3 


81 


161 


82 


*An input string of "l" 


characters 


must 




also be provided. 










predicates listed above are 


those 


which 


were 


presumed 



have all possible bearing on program operation; note that the 
two predicates on "n" were actually unnecessary since "n" is 
totally determined by 
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The test data assertion is that the correct results will be 
obtained for the four test data elements identified in the con- 
dition table; verification was successfully performed by program 
execution . 

The generalization assertion at. B4 is that ix is totally 
determined by the three predicates on listed in the condition 

table (and "ca" is one less than ix) . This was verified by in- 
spection of the program statements between assertions B3 and B4. 

The proof of the synthesized assertion B4 follows directly 
from test data and generalization assertions and Theorem 2.1 (14). 

c. Proof of Synthesized Assertion B5 

It has been shown that assertion B1 preceding the 
call to procedure "read«-and-s-write^input^cards" satisfies the 
input assertion for the procedure, and that the procedure 
correctly assures the validity of its output assertion (B4) . 

Since B4 requires that ca =Z, synthesized assertion B5 is shown 
by the distributed correctness of the called procedure. 

3 . Synthesized Assertion B29-33 

The assertions B29-33 are the output specification for 
the example program. The only significant program statement 
intervening between assertion B5 and B29-33 .in the main program 
is a call to procedure "pal indr ome-«-check" (Figure 10 is a listing 
of the procedure) . Note that assertion B5 satisfies the input 
assertion (B6-8) to the procedure (because B6 is a restatement 
of B5 and the conditionals which constitute assertions B7 and B8 
have antecedents which are necessarily false when jx=£; therefore 
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the conditionals are true) and that the output assertion of the 
procedure (B12) is identical to assertion B29-33. Therefore, 
if the distributed correctness of procedure "palindrome-^check" 
is shown separately and if the procedure call statement is exe- 
cuted for the test cases identified in the verification of the 
procedure, then the synthesized assertion B29-33 is demonstrated 
to be true, and the verification of the main program is complete. 
The correctness of the called procedure is demonstrated in the 
next section. 

D. PROCEDURE PALINDROME CHECK 

Figure 10 contains the synthesized assertions for this pro- 
cedure. Similar to the way correctness of the main program was 
verified by relying on the distributed correctness of this pro- 
cedure, this procedure will be verified by relying on the dis- 
tributed correctness of the procedure which it calls, namely 
"continue checking." 

1 . Synthesized Assertion B6-8 : 

B6 : 2< = $,< = 256 A j x=l a ca= l 

B7: V y[(0<y<jx a bop(y)>l a 0<eop (y)<£) =^> 

— * (text (bop (y) - 1) = text (eop(y) + l))] 

B8: Vy [ (0<y<jx A ~i(eop (y) = 0) ) ==5> 

[string (bop (y) , eop (y) ) =ok a bop(y)>=l A eop(y)< = (L 
a V z ( (0<z<jx A — i(z=y))=> 

C -1 (bop ( z) =bop (y) ) 

A (bop(z) <bop(y) ■==> eop (z) <eop (y) ) ) )] } 

Synthesized assertion B6-8 is the input assertion for the 
procedure. Static analysis of the program reveals that the 
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B6: 
B7 : 

B8: 



B9 : 
B10: 



Bi i : 



B12: 



procedure pa 1 Indrome- check; 

comment find ail palindromes within given text string; 
begin 

comment scan text from left to right; 

C 2<=1<=256 A jx=i A ca= 1 3 
C ^/y[ (0<y<Jx A bop(y)> i A 0<eop(y)< 1 ) =^> 

~< text ( bop( y) - i ) = text ( eop( y) + i ) ) ] 1 

C VyC (0<y< jx A ^(eop(y)=0) 

C s tr ing( bop(y) ,eop(y) )=ok a bop( y) > = 1 eop(y)< = i 
A V^( (0<z<jx A ~< z = y) ) 

( bop(z) =bop( y) ) A ( bop( z) < bop( y) eop(z)<eop( v) ) ) )] ] 

for lx!=2 step i until length_of_text do 
begin 

if text( ix-1) 2 text< ix) then 

C 2< 2 i< "256 A jx>0 A ca = i A B7 A B8 1 
C text( lx— i) 2 text ( ix) a s tar t= lx-i A finish 2 lx 
a s tr 1 ng( ix— i , ix) =ok A 1 < = ix- 1 A ix< = 1 3 

cont inue-check.Ing( ( ix- i ) , ix) ; 
if ix ~= 2 then 

if text( ix-2) = text< ix) then 

C B9 As. text ( ix— 2) = text( ix) A s tart = ix-2 A finis h 2 ix 
A s tr ing( ix-2 , ix) 2 ok A 1 < - i x— 2 a ix< 2 l 3 

cont inue- check! ng( ( ix-2) , ix) ; 

end ; 

C 2< 2 1< =256 A ca= l a Jx >0 a B30 A B3i a B32 A B33 3 
end pa 1 indrome— check; 



FIGURE 10 

PROCEDURE PALINDROME-*- CHECK 
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only call to procedure "pal indrome-'-check" is the call in "main" 
following assertion B5 ; assertion B5 is identical to B6 , there- 
fore B6 holds at the time of the procedure call. B5 ensures 
that jx=l, and because there is no integer y such that 0<y<l, 
the antecedents of the conditionals which constitute B7 and B8 
are necessarily false at the time of the procedure call. There- 
fore the conditionals must be true at this point, and the input 
assertion to the procedure is satisfied whenever it is called. 

2 . Synthesized Assertion B9-10 : 

B9 : 2<=£<=256 a- jx>0 a ca= 9 , a B7 a B8 

BIO: text (ix- 1) =text (ix) a start=ix-l a finish=ix 

a string (ix- 1 , ix) =ok a l<=ix-l a ix<=£ 

The assertion B9-10 is inserted to state that the input 
specification is satisfied for the procedure "continue^checking , " 
which is called immediately following the assertion. All pre- 
predicates of B9-10 are a restatement of the input assertion 
B6-10 (and have not been modified by the intervening program 
statements) except: 

a. text ( ix- 1) =text ( ix) : 

this predicate is assured since control reaches 
B9-10 only if it is satisfied (preceding _i_f statement). 

b. start=ix-l A finish=ix: 

these predicates are true by definition; "start" 
and "finish" are constants, initialized to the values with which 
"continue-<-checking" will be called, which are used in the 
proofs of synthesized assertions. 
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c. string ( ix- 1 , ix) =ok : 

follows immediately from text (ix- 1) =text ( ix) . 

d. jx>0 A B7 a B8: 

these predicates hold on the first loop iteration 
because of the input assertion; they hold on subsequent itera- 
tions due to the distributed correctness of "continue checking" 
(they are contained within the procedure's output assertion). 

The preceding discussion reveals that the synthesized 
assertion B9-10 is always valid; thus no test data and generali- 
zation assertions are required. 

3 . Synthesized Assertion Bll : 

Bll: B9 A text ( ix- 2) =text ( ix) A start=ix-2 A finish=ix 

s tr ing ( ix- 2 , ix) =ok a l< = ix-2 a ix< = & 

The assertion Bll is inserted to state that the input 
specification is satisfied for the procedure "continued-checking," 
which is called immediately following the assertion. In a 
fashion similar to that discussed above, it may be verified that 
assertion Bll always holds, and no test data and generalization 
assertions are required. 

4 . Synthesized Assertion B12 : 

2<=£<=256 A ca=& A jx>0 a B30 A B31 A B32 a B33 
Assertion B12 is the output assertion for procedure 
"palindromed-check" ; the expansions for assertions B30 through 
B33, which are predicates of assertion B12, are given below: 
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B30 : Vx[(2<=x< = £ A text (x- 1) =text (x) ) =#> 

•3y(y<jx a l<=bop (y) <=x- 1 a x<=eop (y) <=£) ] 

B31: Vx[(3<=x<=£ a text(x-2)=text(x) ) ■=$» 

3 y (y<jx a l<=bop (y) <=x-2 A x<=eop (y) <-l) ] 

B32: Vy[(0<y<xj a bop(y)>l a 0<eop(y)<£) =^> 

"A (text (bop (y) -1) =text (eop (y) +1) ) ] 

B33: ^ y [ (0<y<jx A -i (eop (y) =0) ) => 

[string (bop (y) , eop (y) ) =ok ^ bop(y)> = l a eop(y)< = l 
aVz( (0<z<jx A ~ l (z=y))=^ 

( -i(bop(z)=bop(y) ) A (bop (z)<bop (y) eop (z) <eop (y) ) ) )] ] 

The truth of assertion B12 may be verified partially through 
logical techniques and partially through dynamic testing. By 
static analysis it is noted that if during execution of the 
procedure no statements which call "continued-checking" are 
actually executed, then all the predicates of assertion B12 are 
merely restatements of the input assertion B6-8 and are not 
modified by program execution (no positive processing takes 
place) . 

If calls to "continued-checking" are executed, then from the 
output assertion of that procedure and the principle of distri- 
buted correctness (the demonstration of correctness and a listing. 
Figure 11, of that procedure are presented subsequently), the 
following predicates remain unchanged by execution of the pro- 
cedure : 

2<=£<=256 a ca=£ a jx>0 a B32 A B33 

The predicates B30 and B31 will be demonstrated through 
testing in the following manner. If "continued-checking" is 



143 



called with actual parameters "start" and "finish", then its 
output assertion verifies that: 

3y(0<y<jx a l<=bop (y) <=start a f inish<=eop (y) <=£) 
Predicates B30 and B31 are verified, and thus so is the syn- 
thesized assertion B12, if it is shown that: 

^x(2<=x<=& a text (x- 1) =text (x) 

"continue-*-checking" is called, 
with start=x-l and finish=x; and 
Vx(3<=x< = £ a text (x- 2 ) =text (x) ^=> 
"continued-checking" is called, 
with start=x-2 and finish=x. 

a. Test Data Assertion and Verification 

It was presumed from static analysis of this proced- 
dure that if procedure calls are correctly mode to "continued- 
checking" for the first three characters of a text string, 
they will be correctly made for all characters. (Only the 
character patterns over a sub-string of length three are examined 
by the statements which determine whether and when to call 
"continued-checking".) Thus test data were selected to consider 
all possible conditions arising in the first three characters. 

A condition table was prepared as follows: 
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Predicate 



1=2 A 


ix=l 


y 


n 


n 


n 


n 


n 


n 


n 


n 


n 


n 


1=2 A 


ix= 2 


(n) 


y 


y 


n 


n 


n 


n 


n 


n 


n 


n 


1=3 A 


ix=l 


(n) 


(n) 


(n) 


y 


n 


n 


n 


n 


n 


n 


n 


Jl= 3 A 


ix=2 


(n) 


(n) 


(n) 


(n) 


y 


y 


n 


n 


n 


n 


n 


1=3 A 


ix=3 


(n) 


(n) 


(n) 


(n) 


(n) 


(n) 


y 


y 


y 


y 


y 


text (1) = 


text (2 ) 




y 


n 


- 


y 


n 


y 


y 


n 


n 


n 


text (1) = 


text (3) 


- 


- 


- 


- 


- 


- 


y 


n 


y 


n 


n 


text (2) = 


text (3) 


- 


- 




- 


- 


- 


(y) 


(n) 


(n) 


n 


y 


Test Dat 


a: (£) 


* 


2 


2 


* 


3' 


3 


3 


3 


3 


3 


3 




(text) 




bb 


ab 




bbb 


aba 


bbb 


bba 


aba 


abc 


abb 



*These compound predicates cannot be satisfied 
for any input data values. 

The preceding condition table identifies seven unique test 
data elements which were input to the program for. dynamic testing. 
Correct results were obtained for all elements; the correct re- 
sults were defined as being the recording in the arrays "bop” 
and "eop" of entries which included those character positions 
corresponding to all truth values of "y" in the three rows of 
predicates on "text". 

b. Generalization Assertion and Verification 

The generalization assertion is that the preceding 
predicates totally determine the procedure calls made to 
"continue- ( -checking" , and thus the results recorded in the arrays 
"bop" and "eop". Verification of this assertion was not 
formally stated; verification relies on the thoroughness with 
which the applicable condition table was prepared. 

c. Proof of Synthesized Assertion 

The synthesized assertion follows from the 
discussion preceding the presentation of the applicable 
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condition table and from the test data and generalization 
assertions. Sufficiently general theorems to formally state 
a proof of the assertion were not available or forthcoming 
from this effort; however, the careful analysis of predicates 
built a high confidence that the program fragment is correct. 

E. PROCEDURE CONTINUE*- CHECKING 

Figure 11 contains the synthesized assertions for this pro- 
cedure. The input assertion is B13-16; since it was verified 
in the preceeding section that this assertion was satisfied for 
all calls to this procedure, it will be assumed that this 
assertion is satisfied at the time of invocation of this pro- 
cedure . 

1 . Synthesized Assertion B17-18 : 

B17: B13 A B14 A B15 

B18: text(first)=text(last) a l<=f irst<=start 

a f inish<=las t<=£ a string (first , last)=ok 
a (finish=start+l V finish=start+2) A 
(first=l v last=£ V (text(f irst- l)=text(last + l) ) ) 

a. Test Data Assertion and Verification 

Test data were selected using the condition table 
method to consider all predicates which were considered to 
have a bearing on program processing with respect to assertion 
B17-18. The applicable condition table is presented below, in 
two sections. 
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B 1 3 : 
B 14: 

B15: 



B 16 : 



B17: 

B18: 



B19: 

B20: 



procedure cont inue_ checking (Integer value first, last); 
comment Given first and last as pointers to a palindrome 

of size 2 or 3, this procedure checks whether or not this 
palindrome Is included in a larger pallndropiej 

begin 

C 2< = 1< =256 A ca= 1 a jx> 0 1 
C Vy[(0<y<jx a bop(y)>l a 0<eop(y)< 1)^ 

~< text(bop( y)- i)= text(eop( y) + l) )] ) 

C VyC ( 0< y< j x A eop( y) =0) 

[strlng(bop(y) ,eop(y))=ok. A bop(y)>=l A eop( y)< = I 
A Vz( ( 0<z< Jx A ~(z=y) 

( bop( z) = bop( y) ) a ( bop( z) < bop( y) eop(z)<eopi y) ) > )] j ) 

C text ( f Irs t ) = text ( las t ) a gtart=f irst A finish' last 
a g tr lng< f irs t , last) =ok ^ 1 < = s t ar t a finis h<=l 

a ( f In is h=s t ar 1 4 1 \/ f in Is h= s t ar t + 2) } 

logical palindrome} 
pa 1 lndrome : = true ; 

whl le ( ( f lrs t > 1 ) and ( las t< ie ngt h_o f-text ) and ( pa 1 i ndrome 2 true) ) do 
beg i n 

If t ex t ( f 1 rs t - 1 ) = text ( las t+ 1 ) then 

begin 

comment larger palindrome found; 
f i rs t : = f lrs t— 1 ; 
last : = las t+ 1 ; 
e nd 

else 

begin 

pa 1 lndrome : = fa lse ; comment largest palindrome found; 

end } 

end ; 

C B 13 A B 1 4 A B15 1 

C text ( f lrs t )= text ( las t ) A 1 < = f 1 rs t < = s t ar t A f ins lh< = las t< = 1 
a str lng( first, iast)=ok A ( f 1 n 1 a h-s tar t+ 1 V f inish=s tar 
A (flrst=l v las t - 1 v ~< text ( f irs t — 1 ) = text ( 1 as t+ i )) > ) 

record-pa 1 indrome< f lrs t , last) ; 

C B 13 A B 14 a B 15 1 

( 3y(0<y<jx A 1< =bop( y) < =s tar t A f in lsh< =eop( y) < = 1 ) ) 

end contl nue -check.1 ng ; 



FIGURE 11 

PROCEDURE CONTI NUE-*- CHECKING 
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Predicate 



start+l=finish 


n 


y 


y 


y 


- 


y 


y 


y 


start+2=finish 


n 


(n) 


(n) 


(n) 


- 


(n) 


(n) 


(n) 


start=l 


- 


y 


y 


y 


- 


n 


n 


n 


start=2 


- 


(n) 


(n) 


(n) 


- 


y 


y 


y 


start>2 


- 


(n) 


(n) 


(n) 


- 


(n) 


(n) 


(n) 


finish=£ 


- 


y 


n 


n 


n 


y 


n 


n 


finish=£- 1 


- 


(n) 


y 


n 


n 


(n) 


y 


y 


finish<&-l 


- 


(n) 


(n) 


y 


n 


(n) 


(n) 


(n) 


text(start-l)= 


text (finish+1) 


- 


- 


- 


- 


- 


- 


y 


n 


text (start-2) = 


text (f inish+2) 


















Test Data: (£.) 
(text) 


* 


2 

aa 


3 

aab 


4 

aabc 


* 


3 

abb 


4 

abba 


4 

abb 



*These compound predicates cannot be satisfied 
for any input data values . 



Predicate 



start+l=f inish 




y 


y 


y 


y 


y 


y 


y 


y 


start+2=finish 




(n) 


(n) 


(n) 


(n) 


(n) 


(n) 


(n) 


(n) 


start=l 




n 


n 


n 


n 


n 


n 


n 


n 


start=2 




y 


y 


n 


n 


n 


n 


n 


n 


start>2 




(n) 


(n) 


y 


y 


y 


y 


y 


y 


finish=£ 




n 


n 


y 


n 


n 


n 


n 


n 


finish=£-l 




n 


n 


(n) 


y 


y 


n 


n 


n 


finish<£-l 




y 


y 


(n) 


(n) 


(n) 


y 


y 


y 


text (start- 1) = 




















text (finish+1) 




y 


n 


- 


y 


n 


y 


y 


n 


text (start-2)= 




















text (finish+2) 




— 


“ 




"• 


— 


y 


n 




Test Data: ( £) 




5 


5 


4 


5 


5 


6 


6 


6 


(text) 




A 


B 


C 


D 


E 


F 


G 


H 


A: abbad 


B : 


abb cd 




C: 


abcc 




D: 


abccb 


E: abccd 


F: 


abccba 




G: 


abccbd 


H: 


ab< 


:cde 


The preceding 


condition 


tab: 


le identi 


f ies 


fourteen te 



data elements; these were used as input to the program for 
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dynamic testing. Correct results were verified for all ele- 
ments by printing variable values following assertion B17-18 
and verifying that the predicates of the assertion were satis- 
fied. During presentation of the preceding condition table, 
no columns with an "n" entry for the first predicate and a "y" 
entry for the second were added because no new insights to the 
procedure's operation would have been gained. 

b. Generalization Assertion and Verification 

The generalization assertion is that the satisfaction 
of the synthetic assertion B17-18 is totally determined by the 
predicates of the condition table; the only verification was 
the analysis which served as a basis for the preparation of the 
table . 

c. Proof of Synthesized Assertion 

The synthesized assertion follows from the test 
data and generalization assertions. No formal proof could be 
offered. 

2 . Synthesized Assertion B19-20 : 

B19 : B13 /\ B14 a B15 

B20: 3y(0<y<jx a l<=bop (y) < = start a f inish<=eop (y) < = £) 

Assertion B19-20 is the output assertion for this procedure. 
Inspection of Figure 12, the listing and assertions for proce- 
dure "record-^pal indrome" reveals that assertion B17-18, which 
precedes the only call to that procedure, which call in turn 
precedes assertion B19-20, satisfies the input assertion to 
"record-«-pal indrome" , and further that the output assertion of 
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"record-'-palindrome" satisfies assertion B19-20. Therefore syn 
thesized assertion B19-20 is verified by the correctness of 
"record-*-pal indrome" (which is shown in the next section) , and 
test data and generalization assertions are not required here. 

F. PROCEDURE RE CORD^-PAL INDROME 

Figure 12 contains the synthesized assertions for this pro 
cedure. The input assertion is B21-24; since it was verified 
in the preceding section that this assertion is satisfied when 
ever the procedure is called, the input assertion is assumed 
to hold at procedure invocation. 

1 . ' Synthesized Assertion B25 : 

B21 a B22 a B23 A B24 A entry=true 
a. Proof of Synthesized Assertion 

The test data and generalization assertions are 
simply the observation that any and all input data will cause 
the execution of the statement assigning "entry" equal to true 
the rest of the assertion is a restatement of the input asser- 
tion, none of which has been modified. Verification was post- 
poned until the verification of the test data assertion for 
synthesized assertion B26. The proof of synthesized assertion 
B25 follows directly from this observation. 

2. Synthesized Assertion B26: 

(entry=false a B27 a B28) V 
[entry=true A B21 A B22 A B23 A B24 
A Vz (0<z<jx =# ( ” 1 1 (bop ( z) =f irst 
a (bop ( z) <f irst =?>eop (z) <las t) ) ] 
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procedure record-palindrome (Integer value first, last); 
comment Record only max length palindromes. Flag previously 

recorded palindromes if they are Included in the palindrome 
specified by first and last. 

jx was initialized to 1. After completion jx points to the 
next entry in beg in— o f— pa 1 indr o me and end— o f _ pa 1 I ndr one ; 

begin 



B2l: C 2< = 1< =256 A ca= 1 A jx>0 3 

B22: C > tfy[(0<y<jx A bop(y)) i A 0< eop( y) < 1 ) 

~( text(bop(y)-*l) = text(eop(y) + l) ) 3 3 

B23: C VyC (0<y<jx a ~( eop( y) =0) ) =$> 

C s tr ing( bop(y) ,eop(y))=ok a bop( y) > = 1 A eop( y)< = 1 
a ^/z( (0<z<Jx a ~( z- y) ) 

( ~( bop( z ) =bop( y) ) a ( bop( z ) < bop( y) eop( z ) < eo p< y) ) > )J 1 3 

B24: C text ( f irs t )= text ( las t ) A 1< = f irs t< =s tar t A f ins lh< 2 las K 2 1 

a & tr ing( first, las t ) =ok a start< finish 

A(first=l V las t= 1 V ~( te xt ( f 1 rs t — l) = text( last+1) ) ) 3 



integer i; comment local counter; 

logica 1 entry; 
entry: = true ; 

B25 : C B2 1 a. B22 A B23 A B24 a entry=true ) 

for l:=l step 1 until jr-1 do 
begin 

if ( ( f irs t> =begln— of— pa 1 indrorae^ 1)) 

and ( las t < =end_o f _ pa 1 indrome ( 1))) then 
begin 

conrent Palindrome is entirely included In a previously 
recorded palindrome. No entry required; 
entry: = f a lse ; 
e nd 

e lse 

be g in 

If ( ( be gin— o f_ pa 1 indrorae ( i ) >= first) 

and ( e nd— o f _ pa 1 Indrome ( 1 ) <- last)) then 

begin. 

end— o f_ pa 1 indrome ( i ) : =0 ; 
comment flag smaller palindrome; 
end i 

end ; 

end; comment All previously recorded palindromes 

compared with last input; 



B26: C ( entry 2 fa lse A B27 Av 028) V 

[entry 2 true /s B2 1 A B22 A B23 a B24 
A Vz(0<z<jx bop( z) = f Irs t ) 

* bop( z) < f irs t eop(z)< last)] 3 



If entry - true then 
begin 

comment larger than all previous or overlapping or disjoint; 
begin— o f -pa 1 indrome (jx) : - f irs t ? 
end— o f — pa 1 Indrome ( jx) : 2 las t ; 

J x : 2 j x+ 1 ; 
end ; 

B27 : C 2< 2 1< =256 a ca= 1 a jx>0 a B22 a B23 3 

B28 : C 3y(0<y<jx a 1 < - bo p( y) < 2 s t ar t a f i n 1 s h< =eop( y) < 2 1 ) 3 

end record_pa 1 indrome ; 

FIGURE 12 

PROCEDURE RECORD^PALINDROME 
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This assertion is a statement that either entry=false and one 
set of predicates apply, or that entry=true and another set 
apply. If entry=false, no further action will be taken in the 
procedure, and the output assertion is valid at this point. If 
entry=true, the input assertion is still valid, and the entry 
for the current palindrome, which will be the jx-th entry in 
"bop" and "eop", will only be disjoint or overlapping to all 
previous entries in those arrays for which the "eop" entry is 
not zero. 

a. Test Data Assertion and Verfication 

Test data were selected using the condition table 
method to consider all predicates which were considered to 
bear on the program processing with respect to assertion B26. 
The applicable condition table is presented below. 
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Predicate 



eop (i) =0 


n 


n 


n 


n 


n 


n 


n 


n 


n 


y 


y 


y 


first>bop (i) 


y 


y 


y 


n 


n 


n 


n 


n 


n 


y 


n 


n 


first=bop(i) 


(n} 


(n) 


(n) 


y 


y 


y 


n 


n 


n 


(n) 


y 


n 


last<eop (i) 


y 


n 


n 


y 


n 


n 


y 


n 


n 


(n) 


(n) 


(n) 


last=eop (i) 


(n) 


y 


n 


(n) 


y 


n 


(n) 


y 


n 


(n} 


(n) 


(n) 


test data: 


















- 








first 


6 


5 


3 


i 


2 


1 


1 


i 


1 


6 


1 


1 


last 


7 


9 


4 


3 


3 


9 


2 


3 


5 


7 


3 


9 


i 


4 


4 


1 


2 


- 


3 


- 


- 


1 


1 


1 


1 


bop (i) 


1 


1 


2 


1 


2 


1 


2 


2 


2 


2 


1 


2 


eop(i) 


9 


9 


3 


4 


3 


5 


3 


3 


3 


0 


0 


0 


text 


B 


B 


B 


A 


* 


B 


* 


* 


B 


B 


A 


B 


jx 


5 


5 


2 


3 


- 


4 


- 


- 


3 


5 


3 


4 


correct 


























action: 


X 


X 


- 


X 


X 


Y 


- 


Y 


Y 


Z 


Z 


- 



*These compound predicates cannot be 
satisfied for any input data values. 



A: aaaa B: baaabaaab 

X: Set entry = false 

Y: Set eop(i) = zero. 

Z: None required, but program resets eop(i) = zero, 

which is permissable (eop(i) is already zero}. 

As an action, means no action performed; entry 
remains true and a new entry will be made. 



The preceding condition table identifies two input strings 
which were used as input data to the program; intermediate values 
of program values were inspected on each iteration of the for loop 
in procedure "record-f-palindrome" to determine when the compound 
predicates from the condition table were satisfied so that veri- 
fication of the correct action as specified in the table could 
be made. The correct action was observed for each test data 
element.. 
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b. Generalization Assertion and Verification 

The generalization assertion is that the actions 
performed by the procedure are totally determined by the five 
predicates in the condition table; if execution of the for loop 
body performs properly for the identified test data elements , 
it performs properly for all data satisfying the same conjunctions 
of the five predicates. The verification offered is the analysis 
forming the basis for the condition table entries. 

c. Proof of Synthesized Assertion 

Since predicate B23 of the procedure input specifi- 
cation is valid at the entry to the for loop, it cannot happen 
that the current palindrome (string (first, last)) both includes 
a previous entry and is included by a different previous entry. 
Since program action (either entry:=false or eop(i):=0) is taken 
only when one of these conditions exists, repeated execution 
from "i" equal 1 to jx-1 of the loop body cannot cause an unde- 
sirable result such as setting "entry" to false and also setting 
eop(i) to zero for some "i". Thus the synthesized assertion 
follows from the test data and generalization assertions, al- 
though a formal proof cannot be offered. 

3. Synthesized Assertion B27-28 : 

B27: 2<=£<=256 A ca=£ A jx>0 A B22 A B23 

B 2 8 : 3y(0<y<jx a l< = bop (y) < = start A f inish< = eop (y) < = &) 

Assertion B27-28 is the output assertion for this procedure. 

a. Test Assertion and Verification 

The test data assertion is that if the test data 
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elements identified in the first and sixth columns of the con- 
dition table used for assertion B26 are executed to the proce- 
dure's termination, the output specification will hold. The 
correct results were observed, namely that for the column-one 
element no new entries were made to the arrays "bop" and "eop", 
and that for the column-six element the proper (fourth) entry 
was made in the arrrays ; in both cases the output specification 
was observed to hold. 

b. Generalization Assertion and Verification 

The generalization assertion is that the variable 
"entry" divides input to the procedure into two equivalence 
classes and that proper execution of one element of each class 
(as observed in the verification of the test data assertion) 
ensures proper execution for the entire class. 

c. Proof of Synthesized Assertion 

The synthesized assertion follows from the test data 
and generalization assertions; however, no theorem is available 
to formally prove the sets of input data identified are in 
fact equivalence classes. 

This verification of synthesized assertion B27-28 completes 
the demonstration of correctness of procedure "record*-pal indrome" . 
The principle of distributed correctness has been applied to 
show the correctness of the main program from the correctness 
of the called procedures. 
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